TAP RFC [VOSI]

[Alberto Micol]

On 28 Sep 2009, at 00:56, Douglas Tody wrote:

> Hi Alberto -
>
> Did you see my proposed compromise approach just posted today?
Sorry my mail was prepared the day before, and was sent without me  
noticing as
soon as I reached a network.

>
> [...]

>> Are you mentioning a real substantial problem or is it "just" that  
>> is not nice to break the symmetry?
>
> I think interface consistency across a family of interfaces is more
> than just "nice".  Users will expect this, and it promotes code reuse
> in service frameworks and client-side libraries.

Absolutely. That's why the sync / async is really something that  
worries me. see below.

>
>> (Little parenthesis that adds to my confusion regarding all this:
>> I never understood why it is up to the client to specify sync or  
>> async;
>> how can the client know in advance if a query CAN be answered  
>> quickly by a given server? IT CAN NOT!
>> I would think it is up to the server to decide whether to provide  
>> back a sync or async response.
>
> There is some truth in this but it is not that simple.  The service
> interface is quite different for sync and async, with sync being  
> vastly
> simpler on the client side (hence many user apps will try to use this
> unless forced to do otherwise at gunpoint).  If we care at all about
> users who write code we should try to provide sync where we can, even
> if an operation might fail and return a error status.
>
> The exception to this is that a sync request could (if we decide to
> provide it) auto-initiate a job and return a different type of status
> response.  SIAV1 actually mentions something like this, where a  
> getData
> could return a status code indicating that the request was accepted
> and the image was being staged so the client should try again later
> to fetch the image.  This sort of approach can provide a middle ground
> in some cases.

Exactly.
My point is that a client (TAP, SIA, SSA, etc) cannot know in advance  
if its request
is too heavy for a given server. Even more so, if the same query is to  
be sent to many different servers.

To me, a query is always a SYNC query. If the service cannot answer  
right away, the
service will politely inform the client that the request will take a  
bit longer,
and will turn to ASYNC.

Questions are just questions. It is the one providing the answer that
might state: please come back later, now I do not have the answer.

In a SIAP context: provide me a cutout around 3C271. How do I know if  
that service has got all
the images already calibrated and the cutout can be achieved in few  
seconds? It could
be that that service first needs to calibrate all required images  
before being able to cut out
the requested portion, and this might take hours.

If I ASK for ASYNC, then I am FORCING all (TAP, SIA, SSA) providers to  
stage the results on disk for me,
also the ones that could have answered synchronously.
Why forcing providers to do more than they actually need?
It is not good for the data providers' uptake.

I know that all this was already discussed in long TAP friendly  
conversations, but now I see
that this same concept might get extended to other Access Protocols  
"in order to provide consistent interfaces",
and this really scares me out of my wits.

Alberto

PS: <When I'm scared, I joke>  Asking an ASYNC question is not very  
natural:
When I go to the doctor I ask what I have, but usually I do not ask:  
please answer later. :-)
And even worse: when the teacher asked me a question, she never  
mentioned the possibility to answer the day after! :-D Well, you got  
the point.

PPS: Pat promised an answer: eager to read you Pat!


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20090929/fd1cc212/attachment-0003.html>