On Tue Oct 14 20:45:43 2008, Brendan Taylor wrote:
XMPP has mostly avoided Postel's Law. Nobody has to deal with
ill-formed
XML because nobody sends ill-formed XML. Nobody sends ill-formed XML
because nobody accepts it, and what use is a client or server that
nobody can receive messages from?
Ah, be careful, you're convolving two distinct cases - "ill-formed
XML" to me means XML which is not well-formed, and that's a stream
error, pure and simple. I'll call this "Bad XML".
Where Postel's Law applies is that XMPP speakers need to cope with
XML which *is* well-formed, but might not be namespace well-formed.
This, I'll call Bad XMLNS.
I think this is ideal; bad producers never have a chance to enter
the
ecosystem.
But they have and do. It's not very often, I agree, but by stating
that this situation exists, and you mustn't - or shouldn't - choke on
it, I think we're documenting the facts as they are, not as we might
wish them to be.
Moreover, we're then putting ourselves in the position of describing
the situation in terms of interoperability requirements, which is
what those MUSTs and SHOULDs describe. They're not statements of
opinion. They're saying that:
1) Sending Bad XML will break things. So will trying to process it -
the only safe thing to do is give up.
2) Sending Bad XMLNS will probably break some of the things, some of
the time. Trying to process it, though, is fine, and refusing the
process the entire stream will cause you pain.
I'm assuming that, thus far, you agree.
The alternative (limiting what parsers non-toy clients can use,
maybe even
requiring them to write their own or use liberal "XML" parsers) is
ugly.
Please, Brendan, I'm getting increasingly fed up with this persistent
rumour that solving this issue in clients requires some kind of
special parser, or difficult programming, or voodoo in the dead of
night.
Gajim, prior to the fix, used expat. It then tracked namespace
declarations, and built a DOM using a bespoke XML library.
(Substitute Gajim by xmppy, if you prefer).
After the fix, it uses expat. It then tracks namespace declarations,
and builds a DOM using a bespoke XML library.
In broad terms, it's as simple as that - there is really no
difference.
Actually, by far the most complex portion of the patch is the hairy
code trying to maintain the unique way of *generating* XML that Gajim
uses, via the aforementioned bespoke DOM class.
And I'll certainly tell you that not only is the fix easier to do in
Gajim than it would be in our server, it also results in a faster
XMPP network. That margin might not be big in low traffic servers,
but in higher traffic cases it'll really add up. This performance
impact is, for us (and our customers) worth the additional
consideration in choice of client caused by the potentially reduced
interoperability.
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
