[JDEV] Binary XML useful for Jabber?

[Jens Alfke]

David Waite <dwaite at jabber.com> wrote:

> I don't think this last item is there. the LITERAL token (for elements which
> are not in the DTD) reports an offset in the string table, meaning it needs to
> be defined beforehand and not inline.

Look at "inline string extension tokens", the format of which is a magic
number followed by the string itself. The spec's not organized or written
very clearly, but it certainly looks to me as though these let you insert
arbitrary keywords on the fly if they weren't defined upfront.

> I really doubt this would simplify parsing (either in terms of execution speed
> or in Lines of Code).

Sure it would. Binary XML has basically been lexed in advance, and typical
parsers spend about 25% of their time lexing. A lot of the code complexity
is in lexing, as well. It should be really easy to write a BXML parser, and
you could make it plug-compatible with a regular parser like Expat, which
would make it easy to drop into existing code. Generating XML is less
standardized, but hopefully people have modularized their XML generators
such that generating BXML would require changing very little code (I know I
have.)

> If you didn't "decompress" the binary format before
> sending it into Jabber, it would require substantial changes which would
> pretty
> much encompass every line of code.

I haven't looked at the server implementation, but if dependence on XML
syntax is so tightly woven into it, then I have to say it sounds like it's
badly designed. Please don't tell me the modules of the server communicate
internally via raw XML... :-O


Adam Fritzler <mid at zigamorph.net> wrote:

> In any case, the utility of widely available, long-used _generic_
> compression schemes should not be discounted.  Only design/use custom
> schemes where they provide a fundamental improvement in performance

By "generic" I guess you mean zipping the stream. This might get you
something like 2::1 compression, I suppose, at the expense of increasing
code size (have to link in zlib) and slowing down data transfer. But binary
XML would compress the data a lot further since most of the XML element
overhead gets scrunched into a few bytes per, and it would save a lot of
parsing time since the stream has, in effect, already been run through most
of an XML parser.

BTW, I share your low opinion of WAP. But binary XML looks good to me.

> Most wireless transports do not provide reliable, ordered,
> stream delivery. 
> This is why I will probably have AIM on my RIM/Mobitex handheld before I
> have jabber [1].  Because AIM has strictly defined packet boundries.

Jabber has strictly defined packet boundaries too: they're the boundaries of
the top level XML elements within the outer <stream> element. You could
pretty easily break these into individual packets in some hypothetical
non-stream protocol; the absence of an explicit byte count at the XML level
doesn't seem like a big obstacle to me. Of course you'd still need reliable
delivery of the packets, but tell me that AIM doesn't need the same thing as
well!

--Jens