[VOSI] Re: TAP 1.0: sync vs async

[Patrick Dowler]

Prescript: I was off last week, so have many responses coming. I will try to 
divide them into smaller messages and put something indicative in the subject 
line.

On Thursday 16 July 2009 02:24:30 Gerard wrote:
> 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.

Current draft:

$base/async?REQUEST=doQuery&...
$base/sync?REQUEST=doQuery&...
$base/sync?REQUEST=getAvailability
$base/sync?REQUEST=getCapabilities
$base/sync?REQUEST=getTableMetadata

Proposed (e.g.):

$base/async
$base/sync
$base/availability
$base/capabilities
$base/tableMetadata

As a side effect, this makes REQUEST obsolete since there is only one possible 
value (doQuery). On the surface, this is unlike DAL2 (specifically, SSA 1.0) 
which is syntactically like the sync endpoint of TAP. On the other hand, it is 
very much like the VOSpace 2.0 (REST) draft, with service-specific and common 
resources:

$base/nodes
$base/transfers
$base/availability
$base/capabilities

In the previous discussions, we considered this mainly a stylistic issue and 
it looks a lot like DAL-style vs GWS-style :-) However, as has been discovered 
and pointed out, putting VOSI resources under a service-specific resource 
couples the mandatory-ness and I find that to be a compelling reason to make 
this change. Discussions of required vs optional should not be encumbered in 
this way.

On the technical side, Guy is correct that one is forced to write dispatch 
code (the primary thing that application servers do for you) to 
forward/redirect the VOSI requests from the /sync code to some other code. I 
have that exact code in our prototype and even though the metadata I did 
implement is generated dynamically it still makes sense to keep the code 
separate. So in the end you write some logic and forwarding code, you write 
tests to make sure the logic is followed correctly, etc. In the design of our 
TAP 1.0 implementation, it seems that availability is inherently dynamic, 
capabilities are likely very static, and table metadata will be implemented 
dynamically to avoid redundancy (it will be generated from TAP_SCHEMA), but it 
could be static or at least generated, cached, and served as a static 
resource.

If we were to make this change, it would open up the possibility to make one 
or both of sync and async optional and whose presence/support would be 
described by capabilities. Maybe that would be a change for the future as I 
think it is easy enough to relax restrictions. I certainly can see other types 
of services not wanting to require both and hence having to break with the 
style used in TAP (or SSA) anyway, and if that is the case maybe now is a 
better time than later to at least make it cleanly possible by separating the 
VOSI and service resources.


-- 

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