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) > > Two great quotes from the 0mq FAQ: >> Some middleware products do provide their own serialization API. We >> believe that doing so leads to bloated wire-level specifications >> likeCORBA <http://www.omg.org/docs/formal/04-03-12.pdf>(1055 pages). > > Having lived through CORBA hell with in-house projects, I couldn't agree > more.
Amen. >> Note that serialization implementations might not be as performant as >> you might expect. You may need to benchmark your workloads with >> several serialization formats and libraries in order to understand >> performance and which format/implementation is best for your use case >> (ease of development must also be considered). > > 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 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 -Michael ps: it is educating to look at NML/CMS/RCS and apply the above criteria list > > 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 ------------------------------------------------------------------------------ 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
