Help: Naive first run at a flow based programing framework

xuanbao · · 27 次点击    
<p>Hello gophers, I&#39;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 &#34;Node&#34;</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&lt;T&gt;.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&#39;m not really saying that encoding would cost less than a typecast. What I&#39;m suggesting is that there are other ways to provide interfaces for this kind of problem that don&#39;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&#39;t see where you&#39;d need to deserialize twice. you&#39;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&#39;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>
27 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传