TAP 1.0: sync vs async

[Douglas Tody]

Hi All -

What mostly bothers me about this discussion is that not only did we
(some of us anyway) already discuss this some months ago and reach a
workable agreement, but we were supposedly to go to RFC on TAP earlier
this month, and here we are with folks now proposing fundamental
changes to the basic service interface.  At some point, unless an
actual serious problem is found we need to stand by our decisions
and agreements and move on to have a usable interface.

A second issue is the impact of a change such as you are proposing.
Not only is the current TAP spec (and all versions for nearly the
past year) using the current interface model, but also the SSA Rec has
long mentioned getCapabilities as a service operation, and the draft
SIAV2 interface we are currently preparing adheres to this model.
It is not just TAP which is the concern here; we need to have a high
level of consistency among all these services.  The current interface
profile works both for the logical service-with-operations model,
as well as for the more HTTP-specific resource model, and is also
VOSI compliant.  Sync/async/UWS are all adequately supported.  It may
not be ideal for each model but it is not bad.  The alternative which
has been proposed does not support all models and we would no longer
be able to consistently describe the service as a logical interface
composed as a set of service operations.

As I noted earlier, getCapabilities is not just a VOSI interface used
by the registry, but also part of the logical service interface seen
by a client application.  It is used for example to define custom
query parameters in an application such as TSAP, to define the
coordinate systems supported by the service, and many other things
which an advanced client application might want to know.  We want
it to work well for both of these use-cases and what we have now,
the product of our earlier discussions, does this.

>From Paul:
> 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.

Although not explicitly addressed in the older specifications, this
has always been possible; redirects are a feature of the transport
protocol (HTTP) and independent of the logical (transport independent)
service interface.  If a client does a queryData() for example it
would never see the redirect.  Some current services already have
this behavior (although it can confuse simple clients).

 	- Doug



On Fri, 17 Jul 2009, Paul Harrison wrote:

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