[standards-jig] JNG Ramblings.

Wing, Oliver OWing at vianetworks.com
Mon Aug 12 21:44:53 UTC 2002


Mike,

> I'm sorry, but this is really terribly frustrating. I'm spending all
> this time carefully reading mostly knee-jerk reactions to an idea I've
> been thinking about for a long time. Why are you trying to criticize my
> ideas when you obviously haven't read them, let alone thought them
> through?

I understand your frustration, particularly when I did see your original
proposal quite a while back. While I fully understand the problem, and I
personally don't see why a mechanism couldn't be introduced, I feel strongly
it should be both a) optional and b) carefully considered as to not have to
be redesigned radically in the future.

These are just some justifications for my reasoning (many of which have
already been raised);

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.

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;

<stream:error>Error</stream:error>

That on it's own is invalid XML. While this used to be one of the only
examples, with the proposed SASL spec (and also the new c2s protocol), this
problem will come into play here too.

3. Ease of debugging

To me it's a small issue, but still a valid one. 

4. Simplicity

I know JNG is planning on breaking compatibility (which is another issue all
together), but we've managed to do it up till now, and no doubt gained
ground on this alone.

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? 

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


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?

Regards,

--
Oliver Wing



More information about the Standards mailing list