TAP 1.0: sync vs async

[Paul Harrison]

On 2009-07 -17, at 09:52, Guy Rixon wrote:

>
> 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
>


I agree with Guy - whatever technology you are using, as soon as you  
require URL query processing to distinguish between cases, you force  
scripting on the server side, it is not possible to simply allow the  
web server to deliver a static page. However, implementation ease is  
not really the main argument for having a separate end point for the  
VOSI operations - it is the asymmetry/illogicality of allowing the  
VOSI calls on both or one of the /sync and /async endpoints.

Paul.