TAP RFC [VOSI]

[Guy Rixon]

On 30 Sep 2009, at 11:33, Alberto Micol wrote:

> [...]
> All that going back and forth is completely unnecessary (unless of  
> course there is a real
> bug in the question, but not otherwise).
> - If the service decides upfront to use ASYNC (because it offers a  
> huge catalog) the user
> will simply send his query, and the answer will be to please use  
> ASYNC.
> - If the service decides upfront to use SYNC (because it offers  
> access to a small catalog) the user
> will simply send his query, and will receive her answer shortly.
> Of course, the problem arises if a huge catalog is served only in  
> SYNC mode, or if
> a small catalog is served and the network connection is not that good.
> Timeouts will likely  happen often in those two cases. In such case,  
> yes, the user will have to limit
> using MAXREC, if not done so by the provider herself. Some handling  
> of the kind proposed by Pat
> will always happen, but we should limit the number of cases to only  
> the strictly necessary ones,
> balancing it out with the burden otherwise imposed to data providers.
>
> In one sentence: Why complicating things at both ends?
>
> Alberto

There is a third case where an asynchronous query is needed: when the  
query is known a priori to be long-running and the client doesn't  
intend to stay connected. This is possibly rare, but it's exactly the  
sort of special case - large-scale data-mining, basically - where the  
VObs can be worth more than its its predecessors.

We need to make the asynchronous gear optional in services (Gerard  
proposed this months ago), for the reasons you yourself have stated in  
the last few mails. If we did make asynchronous queries optional in  
1.00, then we urgently need a way to denote this in the service  
metadata, as per my earlier email today. This must be part of the TAP  
standard, not the VOSI standard.

However, a generic TAP client is much, much less useful if it ignores  
UWS where offered. It would be a crying shame if the VObs became  
limited to piffling little queries because the application writers  
wimped out. It's a lot simpler to write a UWS client for TAP than it  
is to write the service end.

Cheers,
Guy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20090930/8636f129/attachment-0003.html>