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 > <[EMAIL PROTECTED]> 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/
smime.p7s
Description: S/MIME Cryptographic Signature
