TAP 1.0: sync vs async

[Paul Harrison]

Hi,

I did not make myself very clear, and I used capability and interface  
too loosely - in terms of the actual registration as described in http://www.ivoa.net/Documents/latest/VOResource.html 
  - there could be something like

<capability xsi:type="vs:DataCollection" standardID="ivo://ivoa.net/ 
std/TAP">
  <interface xsi:type="vs:ParamHTTP" role="std-sync" version="1.0">
    <accessURL> http://archive.org/service/tapsync </accessURL>
    </interface>
   <interface xsi:type="vs:paramHTTP" role="std-async" version="1.0">
   <accessURL> http://archive.org/service/tapasync </accessURL>
  </interface>

Which would allow for the end points to be totally separate for the  
two kinds of TAP service. Also I think that if asynchonous or sync TAP  
are allowed separately then it makes even less sense to have the  
predefined structure under base URL as one part of the structure will  
be redundant in many services.

However, having said all that, I can live with the fixed URL structure  
now that TAP is the first DAL service to explicitly allow the full  
power of HTTP, as I can issue a 303 status to any of the requests and  
have the client reissue the request to whatever machine/URL that I  
want for performance/load balancing etc.

Paul.




On 2009-07 -17, at 00:24, Douglas Tody wrote:

> Hi -
>
> As Guy says we already had this discussion some time ago and agreed
> upon the approach currently in the document (now also the basis for  
> our
> planning for SIAV2 and other DAL interfaces).  It would be unfortunate
> to reopen all these issues again at this point in the process.
>
> Unfortunately people have different models for how these things
> should work.  One is better than the other in some cases, but in the
> end it does not make all that much difference, we just need to be
> consistent and pick the best compromise to satisfy all our use cases.
>
> We considered having only ?baseURL and ?baseURL/async (for all
> operations not just VOSI).  I actually preferred this but others
> argued for symmetry with ?baseURL/sync and ?baseURL/async, which
> is a reasonable scheme as well.  Whatever we do we do not want to
> make a special case for this service operation rather than that one.
> 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.
>
> 	- 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

Dr. Paul Harrison
JBCA, Manchester University
http://www.manchester.ac.uk/jodrellbank