TAP RFC [VOSI]
amicol.ivoa at googlemail.com
Wed Sep 30 04:11:17 PDT 2009
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?
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
>> - 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
>> 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?
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dal