[standards-jig] JNG Ramblings.

Iain Shigeoka iain.shigeoka at messaginglogic.com
Wed Aug 14 04:31:52 UTC 2002

On 8/13/02 8:02 AM, "Peter Millard" <me at pgmillard.com> wrote:

> 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.

Oh goodness!  I realize (belatedly) that this is a major problem.  I guess
we just say JNG and hope everyone is thinking in the same direction.  My
thoughts and motivation for JNG are:

1) If you want to do relatively straightforward IM use Jabber as it is
now... Let's call it Classic Jabber (CJ) just to save typing.  As has been
stated many times, the current server and clients seems to scale up to large
deployments just fine.  There are some minor inconveniences in the current
protocols but nothing major enough to stop a reasonably competent developer
(or a group of script kiddies with one ace leading the way) from doing
pretty much anything you need.

2) CJ will need some hackery to properly support namespaces throughout.
Independent packets in documents seems like stretching XML in directions it
wasn't designed for.  Things get complicated if the packets are relayed,
stored, etc.

3) CJ will probably not scale if we are sending a lot of binary data in
band.  In fact any non-xml data seems like a stretch unless we just start
pumping CDATA sections everywhere and encode everything.  Without framing
and arbitrary content it could get pretty ugly once we move out of pure IM.

4) CJ will be difficult to adapt to deterministic delivery.  This makes it
inappropriate to many new markets outside of IM.

5) If we want to see Jabber used for things beyond IM I think change is
going to need to be made.  I'm not too attached to any particular future
direction but I personally would like to extend Jabber beyond IM.

> 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??

If Jabber is IM you're probably right.  I want Jabber to be a messaging
platform tailored to transport XML and collateral data.  IM is just one
application in this scenario.  In that case, I don't see any conflicts with
this extension or change.


More information about the Standards mailing list