A Bit More on Binary Encoding
Update 09/25: A related article in Java Developer’s Journal.
Oh, word got around more easily than I dared to anticipate. Embrace the tubes. Yes, I see now that this issue has been discussed way back then. That’s good, I’ll now try to add only new content on top of what is already said.
My point merely was that as EXI will probably emit some spec at some point in the future, there should be a way to advertise such an encoding feat in the XMPP stream; equivalently to the compression. I’m really not expecting that the group is planning to come up with a pure XML-way to do such a thing, it should be out of their scope. So, nothing too fancy for XMPP, just a basic, minimal advertising feat. And, as a draft can be made (thanks llama for the comment!), more important could be to see if this kind of development would interest the community.
Just to note, I do like the XML data model, about it’s structure and extensibility. And, I must resist the binary XML being the claimed ice cream delicacy (note: this goes a bit beyond XMPP): yes, the binary format is a totally different kind of data, but it still represents the same information – content in some ‘potentially-schema-defined-kind’ of a structure. We’re just not using the debug mode any more (visiting my poor metaphor). And, as the binary format should be the most efficient way to represent that data, it really is the leanest ad-hoc binary format. (No, it won’t be anything absolute in any sense, I’ll be just trying to grasp the basic idea.) It should then be the leanest way to represent XMPP also. Only minor improvements should be able to be gained with further ad hoc binary formats, as the qualitative improvement in reducing the parsing complexity is already achieved. Thus, there should be no room for more efficient ad hoc formats, considering the structure of XMPP.
Irrelevancy prevails: Despite the weaknesses, which of course must be considered, in the evaluation was noted some significant improvements in parsing times. (“2 times faster”, whatever that means.) The article by Sun presented pretty much the same results. And, those gains don’t yet include the impact on software development effort (the error handling I mentioned in the last post); I believe XML parsing could be more robust than what is is today, especially for stream parsing. Well, there might always be tons of perfect solutions hidden inside closed systems or otherwise undiscovered…
It’s the protocol nature where I see a good fit for binary encoding and thus could like to see it supported in the XMPP. Furthermore, the real-timeliness of XMPP could justify RTT improvements.
(Note: There are some comments on the previous post and further commenting is welcome.)