prototype TAP-1.1 service

[Patrick Dowler]

I have updated the CADC TAP service with some TAP-1.1 goodies:

1. VOSI-capabilities describes the standard TAP-1.0 "base URL" interface 
and separate TAP-1.1#sync and TAP-1.1#async capabilities with multiple 
interfaces (differing by securityMethod).

http://www.cadc-ccda.hia-iha.nrc-cnrc.gc.ca/tap/capabilities

I was unable to describe the TAP-1.1 capabilities with TAPRegExt because 
it restricts the standardID to a single value. That makes no sense to me 
since one should be able to use that description to describe any service 
where that metadata is applicable, not just TAP-1.0; it certainly isn't 
supportive of new versions. But the content is hiding there in a comment 
and shows that I would in fact describe my sync and async capabilities 
differently.

2. The default version of our service is now 1.1:

- REQUEST parameter ignored (certainly not required)
- response code of 400 for any bad input
- response code of 500 if there is some server-side failure
- response body still has a VOTable document describing the failure

If the caller specifies VERSION=1.0, they get the old behaviour: 
REQUEST=doQuery required and response code 200 for bad user input (still 
500 for server failure since that is usually out of app control anyway). 
I think this complies to the defined behaviour of VERSION and it would 
certainly help a finicky client. Very useful? I do prefer deploying one 
tap service to two, but since "old" clients probably don't include 
VERSION=1.0 in the parameters they are still going to need a small tweak 
to get working if another change breaks them... and so far the changes 
are minimal so I could make it work, but when I think about having to 
pass the version value into *all* possible code that might make a 
distinction.... *shudder*

3. The async job list (UWS) now supports listing your jobs (must be 
authenticated*) and still gives a 403 (forbidden) for anonymous attempt 
at job listing. Note that we don't ever delete old jobs that are past 
the destruction time so the ist could be long if you don't delete them 
yourself. I am working on a tool to put old jobs into ARCHIVED phase so 
they don't show up in the default listing.

4. The async jobs now support the UWS blocking query (WAIT) with a 
current maximum wait time of 60 (sec), at which point you just get the 
job in the current phase (phase when the wait started). It isn't a very 
fancy implementation: it just does some server side polling of the job 
phase with increasing delta (1, 2, 4, 8 sec then stays at 8) because we 
have 4 web servers and no distributed event notification system in place 
to wake up blockers on a different server from the one actually running 
the job. But, I think this is OK for what it does, which is relieve the 
client from doing polling with all the connection overhead.

* Excercise for the curious: You will have to look in the 
VOSI-capabilities to figure out how to authenticate :-)

-- 

Patrick Dowler
Canadian Astronomy Data Centre
National Research Council Canada
5071 West Saanich Road
Victoria, BC V9E 2E7

250-363-0044 (office) 250-363-0045 (fax)