[standards-jig] JNG Ramblings.
reatmon at jabber.org
Tue Aug 13 11:27:48 UTC 2002
Thank you. This sums up my feeling greatly. My comments in-line.
Wing, Oliver wrote:
>>PS - partly unrelated, but if we're going binary, I wonder if it wouldn't
>>prudent to integrate addressing into the headers. Perhaps some address
>>dictionary so that you could establish a per session mapping of routing ID
>>numbers to particular Jabber nodes/resources. That way routing and
>>processing are completely separate activities and the router doesn't have
> Yes it would be nice to have addressing and packet types, which would make
> routing more efficent. However, I see a couple of issues
> a) The XML still has to be passed at some point. You're simply moving where
> the processing takes place. As hildj has pointed out, scalability is already
> there and proven. (Some of the links recently posted to JDEV on SameTime and
> Exchange discuss performance of those products)
> b) If you're putting addressing and/or packet types into the binary
> protocol, you must take it out of the XML protocol. If you have to leave it
> in there, checking for discrepencies should be done as early in the chain as
> possible. This defeats the 'router doesn't have to understand XML' gain.
These two are basically saying the same thing. The server/router needs
to check the correctness of the XML you are sending and yell at you if
you send bad XML.
If your base packet is XML, then you already have that check built-in.
If your base packet is binary with an XML payload, then you're still
parsing, only you've complicated it because you also have to parse the
XML you're sending.
It's a Good Thing (TM) that we are XML, and not binary. And it's one of
the main reasons I got into Jabber.
> c) The more binary information you add in, the further you move away from
> what Jabber is (not 'has been'). I see this thread turning from how to
> improve XMPP into a discussion for a completely new protocol (which by no
> means is necessarily a bad thing).
I agree. Everyone is talking about a new protocol and not Jabber.
Jabber is XML, it is not binary. Until the official XML spec contains
provisions for binary, Jabber should not be binary.
Is it faster/smaller/more efficient? Probably. But it's not Jabber at
that point. I have several contacts out in the corporate world who have
come to me looking for help with Jabber because their industry is moving
towards XML, and they want to have a good XML router. If what they
wanted was something that could carry XML payloads, then they could just
as easily use a different project.
Our strength is the XML. That fact it's extensible and well structured.
> Oliver Wing
> Standards-JIG mailing list
> Standards-JIG at jabber.org
More information about the Standards