[standards-jig] JNG Ramblings.

Mike Lin mikelin at MIT.EDU
Tue Aug 13 01:17:15 UTC 2002


Hi Oliver, thanks for your comments.

> 1. Existing technologies
> 
> Flash, .NET, Expat and I'm sure others:- They all work near enough
> out-of-the-box with Jabber. By forcing non XML bytes into the stream, you
> make it much harder to implement.

I'm not clear exactly what the deal with Flash is now, but the fact is
that there is special logic in the open-source server because at least
at some point, the regular protocol was impossible to read with Flash.
(This was mentioned here as well as on JDEV in a thread spawned from
this one, and I'm now pouncing on it for the first time.) So I would
dispute the claim that Flash works near enough out-of-the-box with
Jabber; it only does so because we special-case hacked the server.

It's somewhat more arguable with .NET. I think the things that
Jabber.NET has to do in order to achieve asynchronous I/O are pretty
bad, but this is something over which reasonable people can disagree.

Most languages work "easily enough" with Jabber assuming that it is OK
to use synchronous I/O, so that the socket can be hooked directly up to
a non-reentrant SAX parser; then you just need an accumulator for
depth=1 elements (which does not come out of the box). So, I'll concede
that in contexts where binary payload transport is not necessary and
synchronous I/O is sufficient, XML framing is usually OK for limited
purposes.

In languages other than C+Expat, .NET (sort of), and now O'Caml, it is
extremely difficult to use Jabber with asynchronous I/O, because there
aren't reentrant XML parsers. You can either write an angle-bracket
counter, which is hard because angle brackets can appear in places not
related to tag boundaries, or a full-blown reentrant XML parser like
Expat, which is really, really hard. I will state without additional
comment that while synchronous I/O is sufficient for many applications,
asynchronous I/O is useful in many contexts that we would like to
support.

The use of a framing protocol makes it slightly harder for people who
were hooking up SAX parsers to blocking sockets, and immensely easier
for people who need asynchronous I/O. Again, whether this is worthwhile
is something over which reasonable people can disagree, but in addition
to the capability of being able to transport binary payloads, _I_ would
like to pursue it in JNG.

Finally, I'll say that JEP-0017 framing may still be worth considering
for Jabber, current generation.

> 2. Jabber Streams are one document, not many
> 
> There appears to be a misconception that a Jabber document can be broken
> into individual documents (i.e. new DOM structures). This isn't the case for
> fully conformant passing. For example;

I think you're just clarifying a fact about the current Jabber protocol
rather than raising an objection about Mike's JNG, but anyway I'll note
that the design I'm working out dumps the entire concept that a Jabber
session is a streaming XML document; each XML payload is its own fully
self-contained document with its own namespace declarations and so
forth.

> 
> 3. Ease of debugging
> 
> To me it's a small issue, but still a valid one. 

It's certainly a valid issue in general in deciding between binary and
text protocols. I would much rather debug a SOAP wire than a CORBA wire.
But the effect of binary *framing* on Jabber vs. Mike's JNG is vastly
less than in the SOAP vs. CORBA example. Lastly, I think the issue is
made even smaller by tools like Ethereal.

> 5. Encoding
> 
> I'm no expert in this field, and I'm sure DJ Adams would be much better
> equipped to answer this. But say, we work out a way of allowing different
> encoding mechanisms to be used within a single stream (either Jabber
> specific or extension to XML). Could this cause problems? 

Well, since each packet in Mike's JNG has its own fully self-contained
XML document, there's no particular reason why they all have to have the
same encoding, assuming that your XML parser is properly equipped to
detect and read different encodings.

> Likewise, what if your socket library handles the UTF-8 internally?
> Incidently UTF is already an issue in certain languages)

I would piss on a socket library that decodes UTF-8 internally and lacks
a facility to turn this off.

> As a parting question though. Surely Macromedia, when designing Flash XML
> Support though of scability (webpages must handle hundreds of thousands not
> thousands per server) and cross-platform support for the server-side logic,
> and in the end they went for a simple null terminated packet. Food for
> thought?

I actually don't think there is any reason to believe that Macromedia
thought about this in any greater depth than we are here. My money says
that one or two guys at Macromedia did the XMLSocket stuff in an
afternoon, and did the null-terminated packet because they (a) realized
that the type of XML-only framing we use in Jabber was just too hard to
implement and (b) figured it was OK to search all the incoming data for
nulls rather than use length-prefixing. Point (b) again is something
over which reasonable people can disagree, but there is no doubt that
length prefixing is more efficient.

Although I like length prefixing better than both, I would rather have
the null sentinel rather than what we have now. In the general case,
what we have now really is pretty bad.

Thanks,
Mike





More information about the Standards mailing list