[standards-jig] JNG Ramblings.
reatmon at jabber.org
Tue Aug 13 16:09:41 UTC 2002
Mike Lin <mikelin at MIT.EDU> said:
> 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
This is the same argument as "Is a cyborg still human?" How far over can you
go before you are no longer human?
How much binary is ok to throw in and have it still be Jabber?
My view is none.
I've been opposed to Jer's XIB idea from the first day he presented it to me,
and I'll be opposed to this.
> 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.
I wrote my own parser too... but I didn't write it because I had to. I was
using the standard XML::Parser perl module for a while. I wrote my own
because then I could add in features that I wanted to, cut out things I didn't
need, and hopefully have a faster parser.
But saying that you should just be able to use any XML parser out of the box
is like saying you should be able to use any tool out of the box to hammer a
nail. Some tools/parsers are not well designed for Jabber, some are.
> 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.
I agree with pgm. Why are you worried about the machine? If the server is
having issues, then you can look at the code, or throw more hardware at it.
Changing the core protocol and underlying idea behind Jabber is not the answer.
As for simplifying things for the programmer... All you have to do right now,
is open a socket, send XML, and send the incoming XMl directly to a parser.
In your model I would have to add more code to add binary to outgoing packets,
and take the data coming back, strip the binary, and then send the rest to the
parser. All in the name of making the server have to do less work.
Well, there are a lot other tricks we can play with the server and the
protocol before moving to a binary framing packet.
> 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.
It's not baloney. It's one of the core design decisions that was made from
the beginning. Either you accept that, or your don't. Jabber is XML.
Period. It's one of the fresh ideas that seperates Jabber from the other
messaging systems out there.
> 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
> Standards-JIG mailing list
> Standards-JIG at jabber.org
reatmon at jabber.org
More information about the Standards