TAP RFC [VOSI]

[Alberto Micol]

Hi Guy,

Again, I'm not disputing on the usefulness of a ASYNC.
I'm saying that the client should not ask for it (in 95% of the  
cases), and let the service decide how to react.

Is it for that 5% of the cases that we want to build a porsche instead  
of a the famous Andy's bike?

Alberto


On 30 Sep 2009, at 13:02, Guy Rixon wrote:

>
> 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/7916261f/attachment-0003.html>