justin-keyword-jabber.093179 at affinix.com
Sun Jan 18 19:07:21 UTC 2004
On Sunday 18 January 2004 07:03 am, Dave Smith wrote:
> Herein lies the fundamental problem with your arguments -- you're
> approaching this as a traditional XMPP over TCP developer, not a XMPP
> over HTTP developer. This protocol is meant to be easy for developers
> with experience using HTTP, hence the abandonment of the "XML Stream"
> concept, and our customized SASL/TLS negotiation and management
> protocols. Arguing that this JEP is more difficult for _you_ to
> implement, given your XMPP-centric toolbox isn't really a concern to
> me, since you are only marginally the intended audience. The idea is to
> make it easy for non-traditional XMPP developers (i.e. people who
> haven't had a chance to enjoy a persistent TCP connection, etc.) to use
> XMPP in their native environments.
Well, I can't argue with this. For the target audience you describe, it
probably makes sense. However, for the existing 'TCP developer' audience, of
which there are vastly more of us, JEP-25 seems more practical. The fact
that a server can be JEP-25-enabled without even modifying the server code is
compelling, isn't it? I'd rather not see this capability obsoleted. Maybe
there is room for two here.
More information about the Standards