<div dir="ltr">The significance of bloat is less than initially expected. We have built a complete XMPP M2M framework for the WAN side of the equation that ends up with very small packets - certainly smaller than most network frames… Presence and command and sensor readings in practice never exceed the network frame size. Authentication and binding etc is a little onerous, but not overly so and happens rarely. The XMPP extension we have developed for M2M is being used by some large global brands on some fairly large implementations. So far, bloat has never come up (except in the initial technical sales meeting). Nor has latency… We frequently demo turning lights on and off in Asia via a server on the west coast. That being said there are use cases where link local connection is required for both reliability and performance reasons. And in this case we use the same XML stanza's sent via CoAP for these use cases, or where appropriate the native 'association' commands if the end points are on some specialized control protocol.<div> <br></div><div><div>I do agree on the need for using optimized parsers (we have an xml parser that fits in a few hundred bytes of code and read only memory) that is extremely fast and efficient on small devices. BTW the trick to avoid the tag comparison is to convert the various tags and namespaces to hash values as they come in during parsing and then only compare on the hash value. We have a small utility that calculates the hash values and writes as a header file as part of the compile time all the possible namespaces and tag names that we are interested in. Extremely efficient in terms of both computation and memory space. Careful choice of the hash algorithm means very little chance of collision.</div> <div><br></div><div>When looking at 'bloat', the question to be asked is what is the impact on the overall device/system. We have found in practice and at scale that it is not a major issue. It has not measurably affected the latency across the internet either … and from a computational point of view, sending things via SSL is probably a more intense compute than parsing the XML. And that would be done whether Binary or not. You can make the argument that your cell phone data plan is directly affected… but again, in practise it is very small in comparison to everything else going over the connection.</div> <div><br></div><div>I am interested in Alexander Holland's statement "<font face="arial, sans-serif">it's because they are unnecessary for the simple task of sending and receiving messages or presence states". To an extent this is true. We work with a lot of proprietary binary protocols… and transform them to standardized XMPP XML stanza's when something of interest needs to be published to a wide set of listeners in the cloud… or when an external system makes a control request. I think for light weight battery powered sensors that are part of a mesh network then binary makes sense because at that level, every CPU cycle costs battery life. We have found though that on almost any device that is permanently powered and has a network stack on it… the overhead is trivial. I think the key to breaking this argument down is to determine if the WAN has different architectural requirements than the link local level. And that leads to different tradeoffs. That being said we run the XMPP stanza's over CoAP for link local control when we want UDP based IP connections. Because the XML parsing is efficient and and robust to change. And of course you can build that into a binary protocol.. at the cost of simplicity… and then you may as well use XMPP…</font></div> <div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">My two cents worth, based on implementing production quality multi-country M2M architectures using XMPP.</font></div><div><font face="arial, sans-serif"><br> </font></div><div><font face="arial, sans-serif">It works, it is secure, it is scalable and 'fast enough'</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Mat</font></div> <div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif"><br></font></div><div><br></div><div><br><div><br></div><div><br></div><div><br></div></div></div></div><div class="gmail_extra"><br> <br><div class="gmail_quote">On Wed, Dec 4, 2013 at 6:59 PM, Yusuke DOI <span dir="ltr"><<a href="mailto:yusuke.doi@toshiba.co.jp" target="_blank">yusuke.doi@toshiba.co.jp</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hi,<br> <br> I don't oppose your idea but let me do some 'defence' for XML-ish data from industrial point of view...<div class="im"><br> <br> (2013-12-05 08:25), Alexander Holler wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> But my whole point is, that they are bloat in both, code and resource<br> size (I know about in-situ parsers, but even those have to parse).<br> And I don't see any reason why the stuff which goes over the wire<br> should be in a "somewhat" human readable format. And with SSL, that<br> human readable thing is already gone (on the wire).<br> </blockquote> <br></div> Thanks to the 'bloat' we can import external entities such as IEC or IEEE standards. They looks like dinosaurs for net-ish peoples, but they are still alive and growing. And some of such industrial people are trying to use XMPP (OpenADR, IEEE 21451-4, etc.) as data transport and session management framework.<br> <br> For M2M side, I feel there are two schools: JSON-CoAP-IETF-ish M2M and IEEE/IEC/ISO-ish M2M. The both say 'we are the M2M framework' but the field is totally different. Former will born and die rapidly, with high evolution rate. Looks cool. But for (at least some part of) industrial people, doing business over such framework is not acceptable. XMPP, combined with well-defined XML, will be reliable enough (will not die too soon), and has strong schema system to start writing specs without a reference implementation (don't blame me on it, that's the different world :p ).<br> <br> We cannot build long-running infrastructures such as electrical grid, mass transport system, or international logistics system without such 'bloats'. I like XMPP because of it.<br> <br> Regards,<br> <br> Yusuke<div class="HOEnZb"><div class="h5"><br> <br> <br> ______________________________<u></u>_________________<br> JDev mailing list<br> Info: <a href="http://mail.jabber.org/mailman/listinfo/jdev" target="_blank">http://mail.jabber.org/<u></u>mailman/listinfo/jdev</a><br> Unsubscribe: <a href="mailto:JDev-unsubscribe@jabber.org" target="_blank">JDev-unsubscribe@jabber.org</a><br> ______________________________<u></u>_________________<br> </div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><br>Mat Henshall<br>Founder and CEO, Square Connect, Inc.<br>San Jose, CA<br><a href="http://www.squareconnect.com" target="_blank">www.squareconnect.com</a><br> cell: 650.814.7585 </div>