[API] [Standards] Proposed XMPP Extension: IO DATA

Sun Mar 30 18:29:13 CDT 2008

Fabio Forno wrote:
> (I crosspost  this to the API mailing list, because I think that this
> problem is another use case of  the more general problem of p2p
> communication between applications we are discussing; in the API ml we
> can brainstorm better)
> 
> On Sun, Mar 30, 2008 at 8:38 PM, Egon Willighagen
> <egon.willighagen at gmail.com> wrote:
> 
>>  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.
> 
> Indeed, it's interesting in general ;)
> 
>>  1. many different data types. This is particularly a problem in
> [...]
>>  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
> [...]
>>  These two items combined, make this proposal an excellent candidate
>>  for running webservices in sciences like chemistry and biology.
> 
> I understand the scenario, as I've written it's more general than
> scientific or biological computations (e.g send the input events from
> a UI widget placed somewhere to a remote service). Basically you'd
> like to do something like this:
> - retrieve a data scheme from an end point
> - send data to that end point
> - receive (also asynchronously) data from that end point
> 
> Let's try to RESTify it in order to have a more general solution:

What is the particular benefit here of having a RESTful interface?

In particular, do you think that we need to reference each action via a
URI? Such as:

xmpp:compute.example.com?io;node=foo;action=get;data=schema

> - retrieving the data scheme is an operation on a particular node (a
> GET), so we don't need a particular action, just get it from the
> correct node, e.g. GET /nodename/schemata
> 
> <iq from="..." to="..." id="..." type="set">

I think you meant type='get' :)

>     <rest node="/nodename/schemata" action="get" xmlns="api:rest"/>
> </iq>

It might be good to separately specify the node and the data type (in
this case, the schema).

> - sending data is another operation on the node (the semantics of the
> operation on the data is given by the combination of the data and the
> node): POST /nodename payload
> 
> <iq from="..." to="..." id="..." type="set">
>     <rest node="/nodename" action="post" xmlns="api:rest">
>       <header><!-- optional --></header>
>       <body><!-- optional xml payload--></body>
>     <rest/>
> </iq>
> 
> - receiving the result depends on whether the operation is synchronous
> or not. If synchronous it's just the payload of the answer, and we can
> correlate them using the id in the <iq/> stanza.  If asynchronous the
> service should create a session on the client, by adding the session
> id to the headers of the subsequent asynchronous messages (this
> mechanism is application defined, other applications may create a
> specialized node or use other strategies for handling sessions)
> 
> <iq from="..." to="..." id="..." type="result">
>     <rest xmlns="api:rest">
>       <header>
>           <session id="...." xmlns="api:session"><open/></session>
>       </header>
>     <rest/>
> </iq>
> 
> Well, this is just a first attempt to brainstorm... The structure is
> much like HTTP, where we have actions, headers (for carrying optional
> metadata concerning the document) and the exchanged document, with all
> the semantics left to the application. In this way we have the same
> expressiveness of HTTP, with the advantage of a bidirectional
> asynchronous support as XMPP.
> 
>>  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.
> 
> Do you send it all through XMPP? Is it all in small chunks as in the
> examples you wrote, ore there may be also bigger chunks of data? I'm
> asking because I think that everybody here would like to know more
> about real life examples of binary data transfer through XMPP. Keep us
> informed about the performance and the setup you use.

Good question. Typically I think that computational processes might want
to include binary blobs. The question is how best to do that -- e.g., a
<data/> element per XEP-0231 or a reference to a URI where the data can
be retrieved via HTTP or FTP or XMPP or whatever.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/api/attachments/20080330/a8ea55b7/attachment.bin 