[standards-jig] JNG Ramblings.

Mike Lin mikelin at MIT.EDU
Fri Aug 9 16:33:44 UTC 2002


> There are several ways to do it in .NET, but it does work. Further, the
> XmlTextReader (read SAX) has built in support for depth levels, and decent
> namespace handling. As for blocking I/O, it is a valid issue.

It certainly does work, just like it certainly worked for me to write my
own XML parser. :-)

I'm not sayng Jabber XML streams are impossible to do in any language,
in the Turing-complete sense. But it really does cause a very large and
very unecessary amount of pain for many.

> Agreed, but there in you have the issue. To some libraries, it's not an
> issue. By adding framing not only do you break those libraries, but possibly
> making it a lot harder. By adding bytes on a socket, you're preventing
> anyone passing a socket stream directly to a SAX parser, and therefore
> possibly slowing performance and complexity rather than improving it.

I'm trying to make framing reasonably easy for everyone, where now it is
pretty easy for some and really hard for many. I don't mind agreeing to
disagree on which is better here.

I'm very confident that using my protocol will never slow performance,
though, assuming a reasonably competent implementation on both sides. We
should remember that using SAX for Jabber _is_ a hack, because we
virtually always think about protocol elements (message, presence, iq)
in their DOM form.

> I'm all for framing in a form. What I'm not for though is forcing it upon
> anyone. Why can framing not be optional, perhaps an option in the initial
> handshake similar to JEP-0035 allows for SSL?

...or exactly like JEP-0017, which I wrote 6 months ago, specifies. The
framing I'm laying out is also designed to accomodate multipart messages
with possibly binary attachments, so this inherently breaks
backwards-compatibility. But if you turn those off, it's possible to
have the server speak two protocols, sure.

-Mike




More information about the Standards mailing list