[TAP] sync vs async

[Guy Rixon]

On 3 Mar 2009, at 14:44, Roy Williams wrote:

>
>
> Patrick Dowler wrote:
>> In cases where it works, sync is easier for the client, but I  
>> think we  agree that it cannot be made robust in the general case.  
>> Async handles the general case; this is why async is required. For  
>> the small extra work and utility, it was deemed it simpler for  
>> everyone if sync was also required (plus the oddity about VOSI  
>> requests noted above).
>>
>
> Building the asynchronous versions of all these protocols is a  
> large barrier to implementation of VO protocols, it is not "small  
> extra work". Over and above the business logic of the sync service,  
> there will have to be databases of customers and their running  
> jobs, a security infrastructure so that one person cannot see/kill  
> the job of another, a large filespace for storing intermediate  
> results, reaper processes to clean out that space, and other  
> complexities.

Pat actually said that building the synchronous part is little extra  
work if one already has the asynchronous part.

>
> But why Oh Why must this complexity be mandatory? The DAL group is  
> saying (on behalf of the IVOA) that the simple and useful  
> synchonous service is Not Wanted as part of VO. Only large data  
> centers are allowed to publish data the VO way. (In the real world,  
> by contrast, the internet has reduced barriers to publication).

False. "The DAL group" has not said that. AFAIK, no member of the  
group has said that. Roy, this is an important issue, please don't  
degrade the debate by misrepresentation.

What has been said - Pat mentions it in the email that you quote, I  
have also said it, Gerard alluded to it - is that it's hard to make a  
synchronous query-service that works reliably.  There are too many  
ways to time out on an arbitrary query. It can be done with SIAP and  
SSAP and cone search because the implementation defines the DB query  
and one can test the extreme cases. With TAP, the client defines the  
query and it's query tricky to test the edge case against time-outs.

My own opinion is that I don't want to see the VO loaded with  
services that fail at random because the protocols and  
implementations are naive. To me, that is worse than restricting the  
number of publishers. I don't like complicated protocols, but I  
accept them if they seem necessary.

However, I see no reason why a TAP installation that always operates  
quickly has to have the asynchronous mode. I would be happy for the  
asynchronous interfaces to be made optional; but only on the  
understanding that most TAP services will need them and that software  
authors be prepared to add them when that need is discovered.


Guy
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20090303/9389dd5f/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2104 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/dal/attachments/20090303/9389dd5f/attachment-0003.bin>