TAP Implementation Issues (cont'd)

[Patrick Dowler]

On Thursday 22 October 2009 10:51:25 Doug Tody wrote:
> I missed this one in my previous posting.  REQUEST is intended only for
> service operations (doQuery, getCapabilities, etc.).  The UWS mechanism
> is a separate standard and is defined by the UWS specification.
> If we initiate an async doQuery using TAP we need to specify REQUEST
> and the various doQuery parameters when the job is first created,
> but after that the generic UWS mechanism is used to interact with an
> existing job identified by the UWS assigned job id, so there would
> seem to be no further need to specify any TAP-specific parameters.
> Basically once the UWS job is created we are no longer interacting
> with a TAP service, rather we are interacting with the UWS mechanism
> using the protocol specified by UWS.

A minor detail:

My interpretation of the UWS spec and how it applies to TAP specifically is 
that you can post TAP-specific parameters as part of the job-creation and/or 
you can POST them to the job after it is created. That is, you can fully 
specify the job in one POST, then interact with it a la UWS as described 
above, or you can create an empty job and then modify it with subsequent POSTs 
to the job. 

As with all UWS jobs, you can modify the job up to the point that you post 
PHASE=RUN to the phase resource; after that, the job is more or less immutable 
(except for killing the job by posting PHASE=ABORT) from the outside.


> What is the appropriate value of REQUEST for async requests that do
> not create the query?  The document indicates:
>     A TAP client must set this parameter correctly in every request
>     (GET or POST) to /async or /sync web resources.

That text is misleading. It is supposed to mean that you must include a valid 
REQUEST parameter in the job.

When using the /async endpoint, you must post REQUEST=<allowed value> sometime 
before starting execution, as above. There are no GET operations on the /async 
endpoint that take query strings: they just return representations of 
resources. So that should say "every job" and not mention GET or POST at all 
as far as async goes. 

For /sync, the above is correct: you must specify the REQUEST parameter and it 
must be one of the allowed values. Both GET and POST are intended to execute 
and return query results.

> I take this as meaning that invoking something like
>     http://mytap/async/phase
> needs a REQUEST.  

Well, there is no phase resource on the async endpoint, so it would result in 
a 404 (well: technically there is probably not a job with jobID = phase :-) 
But I take your point: the requirement for a REQUEST parameter is limited to 
being set for a job, not for every http interaction. The mention of GET and 
POST makes it sound like every http request rather than every tap request (eg 
every job).

-- 

Patrick Dowler
Tel/Tél: (250) 363-0044
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2M7

Centre canadien de donnees astronomiques
Conseil national de recherches Canada
5071, chemin West Saanich
Victoria (C.-B.) V9E 2M7