[MOBY-dev] RFC #1941 Asynchronous Service Call Proposal

[Robert Buels]

>use the mixed mode. Because if we do so, we cannot use xxx_result as a
>cleaning method (see more about cleaning below), we would need to have
>another method, such as xxx_clean.
>
>   No. Johan is using 'job' for one request (which can have more mobyData
>parts). Once you call xxx_async, the whole such request is identified by a
>'job identifier'.
>  
>
It looks to me like our different interpretations here might be because 
of a lack of clarity in number 2 on page 8 of the RFC.  It doesn't 
really specify whether one mobyStatus block is returned with an asyncID 
referring to all the submitted jobs/mobyData blocks, or whether one 
mobyStatus is returned for each mobyData in the input, with a separate 
ID for each.  I assumed the latter, and I think Martin assumed the 
former.  Whichever way it was intented, I definitely think we should get 
one unique asyncID per mobyData in the input.

So if that's the case, then there would be no difficulties in making the 
xxx_result call be also the cleanup call.  When a xxx_result call is 
issued for a job with asyncID X, you can clean up just the state related 
to asyncID X and leave the others alone.

>   If the call to xxx_result fails, it fails, and you have nothing, and
>you have to start again. This is the sa,e as now with sync services. 
>
Well, it would be kind of nice to have a little insurance.  What if the 
job took a week of compute time?  It would be nice to have a reliable 
way to do jobs like that.  Maybe specifying a xxx_clean method is 
actually the way to go here, in order to have a more robust system.  Or 
maybe one could only have to call the xxx_clean if one specified in the 
xxx_result input that it should NOT clean up?

>   But that's exactly what the proposal is saying. It will be oly one
>service, but it will have more than one method (and a 'method' in web
>services speak is a 'type of request').
>
>  
>
Yeah, you're right, it is just one service, but just with some kind of 
async flag in its spec.  I was sort of thinking of simplicity on the 
implementation side, but on second thought implementing 4 methods versus 
implementing 1 method that's called 4 ways is about the same amount of 
labor.  Nevermind.

>   But I think that INB suggestion that the initial input and the
>resulting output are exactly the same bothy for sync and async is very
>good and valuable, and guarantees backaward compatibility. So I do not see
>here any need to suggest anything else :-)
>
>  
>
Yep, you're right, it's good to have input and output the same for sync 
and async.  Nevermind.  :-)

Rob

-- 
Robert Buels
SGN Bioinformatics Analyst
252A Emerson Hall, Cornell University
Ithaca, NY  14853
Tel: 607-255-2360
rmb32 at cornell.edu
http://www.sgn.cornell.edu