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
