[standards-jig] JNG Ramblings.

Peter Millard me at pgmillard.com
Tue Aug 13 15:02:19 UTC 2002

My comments (Peter) are below...

Ryan Eatmon wrote:
[Oliver Wing]
>> 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.

While I have been reading the posts by Mike et. all, these are the first
ones that have spurred me to respond :) I agree with what Ryan, Oliver (and
previously Marshall) have stated about what the "jabber protocol" is... At
the core, jabber (or XMPP, or whatever :) is XML. Period. One of jer's main
design goals was to leverage XML for the wire protocol because it's easy to
work with, it's extensible, and it's becoming a common theme for lots of
other apps and protocols.

Sure a binary framing protocol might be faster and easier to parse, etc...
but do we REALLY need that??? While the open source server may max out
trying to process packets, the re-written jinc server almost has performance
to burn. Jabber servers can be written to the existing protocol spec such
that they scale well within the bounds of what all IT professionals expect
(and sometimes they exceed that). So my real question here is what's the
point of JNG?? Is it to allow binary payloads in band cleanly (w/out
encoding) ??? Or is it just so that we can more easily parse packets to
improve performance on the OS server?? If it's the later, then I would argue
that there are lots of other ways to tackle the performance of the jabber
server w/out dealing w/ the core protocol first.

If what you're proposing is a binary framing protocol, or some kind of
protocol which encapsulates binary clean payloads, I would argue that it's
_NOT_ jabber (or XMPP) if it's not XML. If thats the case, can we move this
discussion to another list??


More information about the Standards mailing list