stpeter at jabber.org
Mon Jan 19 20:22:09 UTC 2004
On Sun, Jan 18, 2004 at 11:07:21AM -0800, Justin Karneges wrote:
> 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.
So it seems that we need to clearly define:
1. The target audiences
2. The needs of each
Then determine whether we need one JEP or two.
But JEP-0025 does require someone to write a server-side piece, no? No
mere Jabber/XMPP server accepts client HTTP connections out of the box.
Jabber Software Foundation
More information about the Standards