On 9/21/2012 2:55 PM, Kent A. Reed wrote: > 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 Let's hope that two decades from now, we're around to care. :-)
Ken > > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
