Ari Johnson wrote:
Looking at the jabberd code, it does indeed treat these as xmlns and
xmlns:stream attributes on the element. Can anyone explain the reasoning
behind this method, or if a fix might be possible without severely
injuring the Jabber server itself? I really don't want to have to
That's what I was afraid of, but I can deal with it, I'm sure. It's just
frustrating to write something and then realize when you're done debugging
it that you overlooked this kind of thing. Then again, jabberd is
significantly bigger than my code thus far, and it suffers that same
problem,
David Waite writes:
In short, I don't think it is really anything that can be cleverly
hacked in. Either a lot of things will break, or a lot of logic will
need to be added for supporting legacy clients/servers. It has been off
and on the roadmap for the open-source server, but I don't
On Mon, 15 Jul 2002, Matthias Wimmer wrote:
Hi David!
David Waite wrote:
This (together with the 'jabber:server' / 'jabber:component:accept'
namespace usage) would be rather difficult to fix at this point
without breaking interoperability with nearly every client, server,
and
I am writing a distributed computing system based on Jabber, and have been
building it from the ground up as I decided that no existing libraries
quite suit my purpose. So I started writing an XML stream library on top
of expat, and got it working just right. Namespaces work as specified by
