dizzyd at jabber.org
Wed Aug 7 13:25:35 UTC 2002
Yes, I do agree with Rob's assessment that prefixes should apply on a
per document basis (as opposed to a per stream basis).
More responses inline (DIZ)...
On Tuesday, August 6, 2002, at 06:24 , Robert Norris wrote:
>> I've implemented the algorithm to do this twice now, in Scheme and
>> OCaml. In fact, the OCaml XMPP library that I'm going to release Real
>> Soon Now lets you specify namespace associations by URI, while the
>> library handles emitting the correct prefixes. The goals that it has to
>> achieve are straightforward, but the details of actually doing it are
>> intricate and very easy to screw up. Is It Worth It?
> That's exactly the way I'm planning to implement the stream lib for 1.5.
> And yes, its a pain in the arse - since the 1.5 DOM (such that it is)
> assumes that each object is a document unto itself, it effectively
> involves tracking the stream namespaces, and then each packet gets
> initialised with the tracked namespaces, changing the prefixes on the
> fly. It will work, but its very ugly, and I wish I didn't have to do it.
DIZ: In my DOM (objective-c), I create a XMLQName object that tracks the
element name and URI. When I go to write a packet out to the socket, my
serialization routines take into account the default URI for the stream
and then dynamically generates prefixes or overrides the default
namespace as necessary. This work of selecting a prefix and/or
overriding the default namespace _always_ has to be done; we wouldn't
avoid this by going to a packet == document architecture. This concept
simply becomes easier and consistent when we say that the other side
will be able to deal with arbitrary prefixes.
>> I have to say it's my opinion that we should leave Jabber the way it is
>> and just dump the whole "streaming document" paradigm in JNG, so that
>> each packet is a self-contained document. Like using XML structure for
>> framing, the "streaming document" looks nice on paper, but I think it's
>> just not worth it because it's too hard to do right. Anyway, I know
>> is an unpopular position, so I won't push it further (for now).
> I agree completely. The time will come in the not-too-distant future
> where we will need to seperate the transport from the application.
DIZ: I'm not against separating transport for application. As for the
packet == document concept, I think we should probably start that
discussion by looking at some of the archives of JDEV -- long ago there
was a big discussion about that concept...maybe that would give us all
some insight as to why and how the decisions were made. :)
More information about the Standards