[jdev] HTTP gateway

[Jonathan Dickinson]

--------------------------------------------------
From: "Theo Cushion" <theo at jivatechnology.com>
Sent: Thursday, May 20, 2010 3:08 PM
To: <jdev at jabber.org>
Subject: [jdev] HTTP gateway

> Hi
>
> 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 
this problem:
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 
(BOSH).

> 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.

>
> Thanks
>
> Theo
>
> _______________________________________________
> 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
> _______________________________________________
>

-- 
Jonathan Dickinson