[standards-jig] JNG Ramblings.
owing at vianetworks.com
Tue Aug 13 08:48:24 UTC 2002
> > 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,
> > 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.
Fair point, a 'hack' is in there, namely;
a) Accepting a closed flash:stream tag
b) Stripping null characters from incoming
c) Appending null characters to outgoing
But these three simple hacks made Jabber accessible to the millions of Flash
clients out there. Doing a hack for this based on your new proposed protocol
may not be so easy.
> 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
I agree async is where the issue is.
> 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.
Therefore why not make the binary payloads optional? That's my biggest issue
with the proposal, is that it's forced.
> Finally, I'll say that JEP-0017 framing may still be worth considering
> for Jabber, current generation.
I saw this JEP as an optional feature of a server, like the flash 'hack',
and like it. However, as raised in point two, it's dangerous for use within
the current stream protocol.
> > 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
> > 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
Indeed. If we are going down this route, every packet must be considered a
new XML document. We've got away with namespace handling thanks to expat,
but other parsers aren't so forgiving.
> 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.
I don't know Flash well enough to comment, but with Flash Remoting in MX
they are positioning Flash as a fully fledged thin-client enviroment. It
would be of no suprise if Flash became the new web browser. I therefore
don't believe Macromedia would rush through such fundamental decisions which
shape their (can I use this word) OS? [Does anyone know if the framing
technology has changed in MX and it's Remoting protocol? I haven't had a
chance to look at it yet]
More information about the Standards