[Standards-JIG] JEP-0017 Framing: Why was it rejected?

Peter Millard pgmillard at gmail.com
Wed Oct 20 21:11:33 UTC 2004

I hope we're not treating slashdot comments as "Facts" :) From my
experience with jabber.org (I'm one of the core admins), as well as my
day job (I work for jabber, inc), XML processing is the least of our
worries. With highly efficient parsers (expat), and fast processors, I
need to be seriously be convinced that a box can't route packets fast
enough. I think the actual overhead of having to enforce business
logic rules (in RFC 3920) and socket operations are going to be the
biggest problem.  All of this is pure speculation until someone can
post performance test results :)

As a related side note... if you just want something that routes
packets, you definitely don't need a full-blown XML parser.. All you
need is an "angle-bracket parser", and strstr to find the to= bits.


On Wed, 20 Oct 2004 19:47:48 +0200, Heiner Wolf <wolf at bluehands.de> wrote:
> It makes sense in some applications. When the XMPP RFC news hit slashdot.org the only concern was that XMPP is not suited for large scale applications. Message routers must parse all traffic just to find destination addresses. Some people say that in order to process 10.000.000 messages per minute (even distributed over many processors) you need to get to the destination address quickly. You need framing, because 10.000.000 XML parsers cost way too much CPU. Maybe time and performace increases invalidate this argument. But it would be interesting to know what really is the bottleneck in todays very large messaging networks.

More information about the Standards mailing list