Hello, Am 04.12.2013 23:48, schrieb Peter Waher:
> One option, though, is EXI, which "knows" - with some encouragement - to ship > values as binary even though in traditional XML serialization, they'd be > base64 encoded. My only worry is that the level of benefit that this gives is > rapidly eroded by how good XML parsers have got, especially when you consider > the overhead that known-schema causes to the complexity of the protocol. Hmm, I think the question is wrong. It shouldn't be "what are benefits when using a binary represention which doesn't need a XML-parser", it should be "why use a XML-parser at all"? XML might be fine for the message content itself, e.g. if someone likes stuff like HTML-messages, but I don't see why one should take the overhead (regardless how small or large that is) of using XML for the metadatas and other communication related stuff which is only handled internally by software. Why would I want to use e.g. a string instead of a (bingary) number to specify an attribe if no human will see the string (or number) at all? That is, in my humble opinion, just totally unnecessary overhead. Nobody does type stanzas by hand, humans only enter and see the content (excpet for debugging purposes, but for those the SW can represent the binary stuff in any form, even translated to XML). And in times of encryption the stuff on the wire already isn't readable anymore. But thanks a lot for the pointer to EXI, I'm not up-to-date with all the new existing protocols (and will have a look at EXI) and just started that discussion in response to using XMPP for M2M. It wasn't my intention to change XMPP or speak about XMPP 2.0, I just wanted to mention that I would not like to use XMPP in the existing form for M2M. Unfortunately that ended up in a discussion about XML-parsers and why change XMPP. ;) Regards, Alexander Holler
