[jdev] HTTP gateway
jonathan at dickinsons.co.za
Mon May 24 02:21:14 CDT 2010
From: "Theo Cushion" <theo at jivatechnology.com>
Sent: Thursday, May 20, 2010 3:08 PM
To: <jdev at jabber.org>
Subject: [jdev] HTTP gateway
> Due to the asynchronous nature of XMPP this makes for quite a different
> programming style under the hood to ensure everything has worked
> smoothly - or adopt a very naive approach of fire and forget.
I could see how this could be a problem, but XMPP *does* actually deal with
1. Message nodes SHOULD be guaranteed to be delivered.
2. IQ nodes always respond. I can't remember the exact XEP - but there was
one that dealt with 'progress reports' from long-running IQ processes. Maybe
someone could fill in this blank?
> I keep seeing solutions to this type of thing involving custom ejabberd
> modules and the like - but this tends to result in lock in and makes
> support difficult (what happens when ejabberd internals get updated), we
> also loose features like decentralisation. It is proving a problem for us
> in that the 'best practice' for writing this type of code is totally
> unknown - and concepts familiar to web developers are unused.
Depending on your problem this is unavoidable. Some problems can be solved
completely distributed (on the client); while others simply can not. Maybe
if you gave us an example?
> An idea I have been toying with for a while is an HTTP gateway that
> operates in a similar way to RESTful services ( please forgive me :-) ),
> for operations which typically involve IQ stanzas and dataforms where we
> care a lot that they get done correctly - and less so about using the
> most efficient transport.
I believe you are looking for this: http://xmpp.org/extensions/xep-0124.html
> So what I propose is building a HTTP service which provides a convenient
> interface for configuring XMPP servers. This would probably use HTTP
> basic access authentication
No no no! :) . Rather stick with SASL please; HTTP does support it under the
covers. Of course PLAIN is fine if you are running via SSL/TLS, but does not
fit nicely into the XMPP stack.
> to deal with login and then build upon the URI's specified in the XEP's
> to provide a very simple synchronous interface which other application
> developers can hook into and still allow them to use all of the awesome
> XMPP features - but control it in a way they find easy.
> What are peoples thoughts / criticisms / suggestions?
I remember there was a XEP about XMPP via SOAP - I am not sure what came of
that. That would be an interesting start if you have a SOAP jscript library.
Regardless I would be interested to see what you come up with. Best of luck.
> JDev mailing list
> Forum: http://www.jabberforum.org/forumdisplay.php?f=20
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
More information about the JDev