TAP 1.0: sync vs async

[Guy Rixon]

On 17 Jul 2009, at 00:24, Douglas Tody wrote:

> To a client application getCapabilities is a service operation just
> as much as eg queryData.  They should be provided in the same way.
> We should be able to just compose the URL with a standard pattern with
> no special cases.  Providing direct access to a static file as Guy
> suggests is something we want to enable, but this is easy to provide
> with any of these schemes, and it is nice to have a scheme which can
> also enable dynamic generation of the Capabilities, table metadata,
> or whatever from more fundamental metadata.  What we have now works
> for all of these use cases.   I could go on - this is a brief rehash
> of the earlier discussions.

Actually, I don't find it at all easy to implement VOSI table and VOSI  
capabilities
with a document once they are conflated with a TAP resource - i.e. if  
both
VOSI and TAP things are in the same web-resource and distinguished  
only by
a query string. I can do it in Java using internal redirection, or I  
can do it by
redirecting the client, but both are extra, unnecessary machinery.

Conversely, I find it easier to implement VOSI resources as a dynamic  
services
if they are separate from other resources. I have done so in some of  
the AstroGrid
software, by adding a simple servlet that just does VOSI. If I have to  
bundle
VOSI generation into a TAP servlet it will be extra work and unwanted  
complication.

Guy




>
> 	- Doug
>
>
> On Thu, 16 Jul 2009, Guy Rixon wrote:
>
>> Hi Gerard,
>>
>> I support your suggestion that the VOSI resources be siblings of  
>> the TAP sync and async resources.
>>
>> This was discussed at length in the drafting of TAP 0.3x, but the  
>> editors did not get a consensus in favour, only a majority.
>>
>> Separating the VOSI resources has an important advantage: the  
>> capabilities and tables resources can then be implemented as a  
>> static XML-document. When VOSI is combined with the TAP-query  
>> resources, requests for capabilities and tables have to be  
>> generated (or at least mediated) by servlets or scripts.
>>
>> I note that the VOSI spec doesn't mandate any particular URL for  
>> the VOSI resources. Including them in sync is allowed; separating  
>> them is also OK.
>>
>> Cheers,
>> Guy
>>
>> On 16 Jul 2009, at 10:24, Gerard wrote:
>>
>>> Dear colleagues
>>> In the recent interop the issue of whether support for synchronous  
>>> queries
>>> should be mandated, or async, or both was mentioned, but not really
>>> discussed further in the relevant sessions. I would like to once  
>>> more bring
>>> this up though.
>>> My proposal is still that we mandate that sync OR async is  
>>> supported, or
>>> both.
>>> There are use cases where sync allone suffices, and whatever some  
>>> experts
>>> argue, sync is easier to support in a robust manner than async.
>>> On the other hand there are use cases where async is clearly the  
>>> best
>>> option, and sync might never be desired, so async alone should  
>>> also be
>>> possible.
>>> We have had discussions on the mailing lists some months ago and I  
>>> guess we
>>> do not need to rehash those.
>>> One "argument" against leaving it optional to support sync is that  
>>> the VOSI
>>> requests are currently implemented on the sync/ end point.
>>> Irrespective of how we decide on sync vs async, I propose the VOSI  
>>> requests
>>> should NOT be put on top of the sync/ end point, but "next to"  
>>> sync/ and
>>> async/. They are different things from the actual service requests  
>>> and
>>> should/need not be mixed with them.
>>> All these points were discussed with various people right after  
>>> the closing
>>> of the interop, when I realised that they had not been discussed.
>>> There was general agreement (about 8 people were included in the  
>>> discussion,
>>> I will keep their identities secret) on all these points.
>>> I promised to bring this up during the RFC, so here you have it.
>>> Best regards
>>> Gerard