[standards-jig] JNG Ramblings.

Mike Lin mikelin at MIT.EDU
Tue Aug 13 15:44:39 UTC 2002

It's partly about performance. It's partly about making it *possible* to
use asynchronous I/O without jumping through absurd hoops. It's partly
about being able to transport binary payloads. For me, it's partly about
having a framing protocol that is so simple as to have mathematical

My understanding (maybe I'm wrong) is that you wrote your own XML parser
for JabberCOM. Having also recently written an XML parser, this is a
feat that deserves praise, but you should simply have been able to use
an XML parser out of the box. That, in addition to the transport of
binary payloads, is what my JNG enables.

Again, it's still an XML-oriented protocol. We just sprinkle a few bytes
here and there that vastly simplify things for the machine - and, in
many cases, for the programmer. 

Frankly, I think these "it's not all XML so it's not Jabber" arguments
are just baloney. Jabber uses XML in ways it was never intended to be
used, and is in no way an appropriate tool for. We've paid for it with
dozens of angle-bracket counters, multiple lexings and custom parsers.


On Tue, 2002-08-13 at 11:02, Peter Millard wrote:
> 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).
> [Ryan]
> > 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.
> (Peter)
> 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??
> pgm.
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig

More information about the Standards mailing list