I preface this post with the acknowledgement that these areas are a movable feast, and at some point you just have to ship something.... I also ack that I'm not 100% conversant with MK's use cases and requirements.
Nonetheless, I believe the following might be of interest. There are now several message formats that offer considerable speed advantages over Protbuf. In fact I wonder if it isn't possible to simplify MK by replacing ZeroMQ and Protobuf with something like Cap'n Proto, Maybe ZeroMQ + Flatbuffers if the MK components are (as good as) stateless and even SBE if random reads of messages is not required? For what it is worth I think the Flatbuffers note, see [3], that Cap'n Proto has "no optional fields to allow deprecating fields or serializing with missing fields for which defaults exist" might not be all it appears to be when you review [1]. In my opinion, the feature comparison in [1] is more credible than that at [3]. The issue seems to come down to how stateless/stateful are the different components of MK. My naive understanding is that the important parts MK are stateful. I won't by surprised to find out that is naive - kinda like that moment you were exposed to the dual representation in LP. Nonetheles I found these interesting, [1], [2]. In particular [2] was interesting for the comment that, given their targeted use cases it would make more sense to build ZeroMQ on Cap'n Proto rather than pass Cap'n Proto messages around with ZeroMQ. I might have the wrong end of the stick here.... Earlier I posted a comment that I wondered if driving and interacting with a 3D-Printer or any CNC machine wouldn't be easier/best using a FSM (if this was true Ragel was the suggested building block), If that idea isn't nuts, then I also wonder if ZeroMQ + Protobuf aren't doing together what Cap'n Proto can do alone? Again I have little insight into how much method chaining there is between MachineTalk mediated components, so the benefits may not outweigh the costs of switching. Anyway, hope someone found these new or interesting [1] https://capnproto.org/news/2014-06-17-capnproto-flatbuffers-sbe.html [2] https://capnproto.org/faq.html [3] http://google.github.io/flatbuffers/md__benchmarks.html On Monday, May 1, 2017 at 2:33:35 PM UTC+10, Alexander Rössler wrote: > > I wrote a blog post about the design decisions behind Machinetalk some > time ago: > > http://machinekoder.com/machinetalk-explained-part-2-middleware-requirements/ > > ZeroMQ won the game because is was the best networking middleware choice > for this application the time we started to work on Machinetalk. > > With Machinetalk GSL, Machinetalk also becomes transport agnostic. That > makes things like WebVCP possible. > > Am Freitag, 14. April 2017 07:12:25 UTC-5 schrieb Hedge Hog: >> >> Thanks Schooner, I wasn't aware it was dead - unfortunate. >> >> On Friday, April 14, 2017 at 9:50:30 PM UTC+10, Schooner wrote: >>> >>> >>> On 14/04/17 12:33, Hedge Hog wrote: >>> >>> Hi, >>> I'm new to Machinekit, via the world of 3D Printing. I'm new there too, >>> but doing my homework on 'best-practice' around boards and drivers lead me >>> here (via grbl, marlin, linuxcnc). >>> >>> I was very impressed you're using zeromq - my experience is that not too >>> many know about it outside of finance (at least that was true 7 years >>> ago). >>> It was that project choice that convinced someone here knows what they >>> are doing. >>> >>> Given that the use of ZeroMQ is in its early days in Machinekit I have >>> to ask: >>> >>> >>> It has been used since before the split with linuxcnc, so longer than >>> Machinetalk has existed as a separate entity >>> >>> Was there a reason(s) nanomsg wasn't adopted? I'm assuming it existed at >>> the time :) >>> Are there plans to migrate to nanomsg? >>> >>> >>> Shouldn't think so, the nanomsg project seems to have imploded whereas >>> zmq is actively maintained >>> http://sealedabstract.com/rants/nanomsg-postmortem-and-other-stories/ >>> >>> If it does what we need, why change? >>> >>> >>> >>> Best wishes >>> Hedgehog >>> -- >>> website: http://www.machinekit.io blog: http://blog.machinekit.io >>> github: https://github.com/machinekit >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Machinekit" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to machinekit+...@googlegroups.com. >>> Visit this group at https://groups.google.com/group/machinekit. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- website: http://www.machinekit.io blog: http://blog.machinekit.io github: https://github.com/machinekit --- You received this message because you are subscribed to the Google Groups "Machinekit" group. To unsubscribe from this group and stop receiving emails from it, send an email to machinekit+unsubscr...@googlegroups.com. Visit this group at https://groups.google.com/group/machinekit. For more options, visit https://groups.google.com/d/optout.
