<p>Hello gophers, I'm toying with the idea of creating an at runtime reconfigurable gui driven flow based programing framework (basically a <a href="https://nodered.org/" rel="nofollow">nodered</a> like system). </p>
<p>While this is mostly an academic I plan on using it to run some home automation features.</p>
<p>Anyways, I was hoping to get some feedback on the programing API visa vi what its like to define a "Node"</p>
<p><em>DISCLAIMER</em> this code is pretty rough but I would like any feedback you can give me!</p>
<p><a href="https://github.com/pborges/flow/" rel="nofollow">https://github.com/pborges/flow/</a></p>
<hr/>**评论：**<br/><br/>twek: <pre><p>This is one situation I would love to have generics, <code>Source<T>.Exec(T)</code> would be much nicer then <code>Source.Exec(interface{})</code></p></pre>whizack: <pre><p>If the purpose of Exec is to pass mutable data, the flow nodes should serialize to bytes (probably using gob) between links. Using interface{} and func(interface{}) error is just a lazy abstraction in this case.</p></pre>twek: <pre><p>The purpose of Exec is to pass data, not necessarily mutable but I could it could be, but even if I did serialize and pass bytes I would have to deserialize and check for type errors on the other side, that sounds a lot more expensive then a type check </p></pre>whizack: <pre><p>I'm not really saying that encoding would cost less than a typecast. What I'm suggesting is that there are other ways to provide interfaces for this kind of problem that don't involve generics.</p>
<p>The benefit of moving to a byte encoded format is that if you wanted to create distributed/networked flow graphs, the concept of moving data between remote nodes is already part of the usage pattern.</p>
<p>Barring that, you could probably use context.Context instead of a straight interface{}, which might be a good improvement allowing for deadlines/timeouts per node action.</p></pre>twek: <pre><p>Deadlines is probably a good idea. For the most part this is supposed to be a real time like system, so at run time you would do something like wire a door sensor to a buzzer. Or wire a node that is outputting the temperature to a PID node with the output going to a node representing a fan.</p>
<p>But even if i serialize I still have no idea what kind of data is in the byte buffer unless I have a predeclared envelope type and want to deserialize twice right?</p></pre>whizack: <pre><p>i don't see where you'd need to deserialize twice. you'd send bytes (or an io.Reader) to Exec() and the node would unpack, do some logic, then return a Reader or bytes to the engine for the next node in the chain to process. You'd never unpack the envelope twice.</p>
<p>that said, I can see why in an embedded/iot context that slowing things down (even by a little bit) could have a big impact on responsiveness for large flows.</p></pre>
