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

[Paul Gordon]

I am pretty much in agreement with all of Martin's points, especially 
using the existing mobyData tag and formulating job-ticket-like 
objects.  As a client interface builder, this is MUCH more convenient 
for me...

>>Well in that case, the queryID and asyncID are redundant aren't they?  
>>They are both just unique pointers to identify a certain mobyData  
>>block.
>>
>>    
>>
>   They are not the same, at all: First, queryID is defined by a client,
>not a service provider - and two clients cannot guarantee that they assign
>different IDs. Second, asyncID must be unique even for more requests (of
>the same service, at least), but queryID does not need to be. For example,
>as a client I can send two requests, both with the same queryID, but I
>expect that the service provider distinguis them when I am polling for
>their status.
>
>  
>
>>It would be good though to have an additional ID / ticket to  
>>represent a session (that might be based on user's credentials etc.).
>>
>>    
>>
>    Agree. That's what I suggested. 
> 
>  
>
>>I think we definitely need one mobyStatus per mobyData block. So I  
>>disagree with Martin there. If Martin wants to keep things simple he  
>>can always summarise all the mobyStatus elements for one session and  
>>tell a user whether the whole batch has finished or not.
>>
>>    
>>
>   I already said that I do not mind to have states of individual mobyData
>blocks (named jobs, as we all in the meantime agreed). Fine with me. But I
>keep telling that I *mind* to use mobyStatus tag (but that beongs
>somewhere else).
>
>   Good to have you on the discussion,
>   Cheers,
>   Martin
>
>  
>