On Sun, Mar 30, 2008 at 7:09 PM, Fabio Forno
<fabio.fornogmail.com> wrote:
>  While it's true that in SOAP+XMPP specs there is no
asynchronous
>  message exchange pattern (and that was a mistake,
though I think it's
>  possible to add a new MEP), this is not related to
REST. Neither the
>  concept of session id is somewhat related to REST, at
the contrary,
>  REST explicitly forbids things like session ids.

Fabio,

thank you for catching this misqualification. We'll fix this
shortly.

BTW, let me say that asynchronous RPC support in XMPP is
very
interesting for scientific workflow environments. This
proposal
addresses two problems which are important limitations of
current
approaches like SOAP over HTTP.

1. many different data types. This is particularly a problem
in
(bio-)chemical sciences, where experimental data is found in
many,
many data types, which, moreover, are increasingly
semantic.
Currently, SOAP often cannot validate input unless the call
has been
made, while this proposal promises to allow to do this at
the gate.
Big improvement.

2. asynchronise calls. This is also a big limitation of our
current
tools. Call-by-reference does solve the problem of HTTP time
 outs on
intermediate IP packet routers, but the only way to do long
running
jobs is to have the client use a second 'service' to poll
the primary
service and ask if it is done yet. XMPP is provides a much
nicer
protocol for such situations, and this proposal formalizes
this.

These two items combined, make this proposal an excellent
candidate
for running webservices in sciences like chemistry and
biology.

I am not too much into XMPP myself, but hope the discussions
on this
mailing list will help us get the proposal in shape, because
we really
like to see this functionality. The example code from
Johannes looks
great, and eager to start using it. We are setting up
webservices for
metabolomics, where the data that needs to be passed around
goes in
the gigabytes, and where processing easily goes into the
tens of
minutes.

I am aware that we continue the unofficial extension of
Edrin, but
having this as an official XEP will make it much easier to
roll out
XMPP-based webservices on a larger scale.

Looking forward to hearing further comments!

Egon

-- 
----
Post-doc in Metabolomics
Wageningen Universtity & Research Center, The
Netherlands
http://chem-bla-ics
.blogspot.com/