On 9/21/2012 1:53 PM, Michael Haberler wrote: > Am 21.09.2012 um 18:22 schrieb Kent A. Reed: > >> On 9/19/2012 6:30 PM, Michael Haberler wrote: >>> -- when the time has come to send a status update message, go through the >>> member list, pull current values, and create a status message (this would >>> have to call upon the serialisation method employed in the future, for >>> instance Google protocol buffers, or JSON, or whatever we decide on) >>> >> <...> >> I only know JSON, and that not so well. Is there some simple but >> relevant benchmark that could be cobbled up to explore it vs the rest of >> the contenders? > There are some, but I'm unsure whether they are terribly relevant for us, e.g. > http://stackoverflow.com/questions/2000933/protocol-buffers-versus-json-or-bson > http://www.4feets.com/2009/08/serializing-data-json-vs-protocol-buffers/ > > the overall criteria I'm looking at are (roughly in descending importance): > > - degree of, and options for type checking (iow: IDL-based versus loose > typing; I'm very lukewarm about loosely typed approaches here even if they > are 'convenient') > - bindings for 'our languages' available without resorting to low-level API's > - support for introspection (e.g. inspecting variant messages), again without > low-level API's > - support for optional, 1-n-repeated fields, and reuse of existing > 'submessages' (compound structures) > - versioning support without need for recompilation > - language independence (for instance, cuts out Python pickle - no decent C > support) > - size and fit of user base, and developer community - avoid one-man shows > - quality of documentation and examples > - maturity of packaging > - community fit - the technology must be easily understandable and 'close' - > no esoterics please > - conversion to/from textual external representation automatic (iow: you can > write a stream of motion commands with the editor, and play it; or record one) > - encoding/decoding speed - only one aspect > - transport-mechanism independence - no integrated serialisation plus RPC > thingies - one function only > - external dependencies (e.g. malloc required or not? if yes: here comes your > memory leak;) > - suitability for in-kernel use - not sure if thats really needed
This is a great list, Michael. Not that it matters, but I'm not sure I'd order it in quite the same way. Language independence and high-level bindings for our languages seem to me equal in importance and almost a meta-must. Auto-conversion to/from external text representation is a big winner for me. It's a godsend for developers, bug chasers, those learning the system, talented hackers. As well, it's a nice reflection of the Tao of Unix. Type checking is an interesting subject. I went from one extreme with CORBA and IDL to the other extreme with a pub/sub infrastructure that cared only that the XML messages being passed around were well-formed. I assume you see a middle ground. > My current ordered short list is protobufs, and with some distance followed > by BSON and then Json; I have most experience with protobufs and after a > while found it very easy going; the learning curve is OK and documentation & > support fine. > > wrt benchmarking, I guess what I'll do is record a motion and status stream > for a few sample programs to arrive a 'typical' message type distribution, > and build a strawman encoder/decoder for the say top 80% and see how that > fares; note the current use is heavily tilted towards emcstat retrieval which > need not be if change- or event driven updates were available; but even a > ballpark figure helps Cool. I don't care personally what choice is finally made, I just like to see choices being made rationally. > -Michael > > ps: it is educating to look at NML/CMS/RCS and apply the above criteria list > Let's hope that two decades from now, this LinuxCNC3 work remains so useful that someone else cares to show how we erred this time around :-) Regards, Kent ------------------------------------------------------------------------------ Got visibility? Most devs has no idea what their production app looks like. Find out how fast your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219671;13503038;y? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
