If were looking at protocol buffers , I think upb , https://github.com/haberman/upb/wiki would be nice to look at.
/ Lars 2012/9/22 Michael Haberler <[email protected]>: > > Am 21.09.2012 um 20:55 schrieb Kent A. Reed: > >> 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. > > I used to think IDL's are just another dependency which create a clunker of > auto-generated code which nobody cares to read and is hell to find a bug in; > and there's something to that > > but there's one aspect which makes an IDL like protobuf extremely convenient > - namely if it autogenerates a high-level binding for a message format; for > example the following is hard to beat by manual coding: > > 1. define a message format like here: > http://git.mah.priv.at/gitweb/emc2-dev.git/blob/93d0baf050f68989b07ac71b60b976f982c7ee70:/src/hal/halnotify/report.proto > 2. compile it into Python bindings like so: > > hal/halnotify/report_pb2.py: hal/halnotify/report.proto > protoc $(PROTOC_FLAGS) --proto_path=hal/halnotify/ \ > --python_out=hal/halnotify/ hal/halnotify/report.proto > > 3. write a real complex application for said message format like so: > http://git.mah.priv.at/gitweb/emc2-dev.git/blob/93d0baf050f68989b07ac71b60b976f982c7ee70:/src/hal/halnotify/sub.py > > 4. and get the thing into Python fully automatic, with external > representation (and back too - not shown here): > http://git.mah.priv.at/gitweb/emc2-dev.git/blob/93d0baf050f68989b07ac71b60b976f982c7ee70:/src/hal/halnotify/sub.log > > - Michael > >> >>> 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 > > > ------------------------------------------------------------------------------ > How fast is your code? > 3 out of 4 devs don\\\'t know how their code performs in production. > Find out how slow your code is with AppDynamics Lite. > http://ad.doubleclick.net/clk;262219672;13503038;z? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ How fast is your code? 3 out of 4 devs don\\\'t know how their code performs in production. Find out how slow your code is with AppDynamics Lite. http://ad.doubleclick.net/clk;262219672;13503038;z? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
