TAP RFC [VOSI]

[Doug Tody]

On Thu, 24 Sep 2009, Guy Rixon wrote:

> I vote for using resources.
> I have a TAP implementation that has VOSI both as resources and via the 
> REQUEST parameter.

Hence it is quite easy to support both approaches in an actual
implementation.  And since with VOSI an opaque URL is used to define
the VOSI endpoint in the registry, if an implementation wants to add a
REST URL to implement getCapabilities or other VOSI operation in their
service, applications which are based upon the VOSI interface will
automatically take that route.  So this is available in either case.
But if we remove REQUEST then it just breaks the REQUEST/VERSION
based interface model and there is no way of getting around it for
client applications which use that model.

 	- Doug

>
> On 24 Sep 2009, at 15:07, Patrick Dowler wrote:
>
>> On Monday 14 September 2009 02:00:09 Keith Noddle wrote:
>> > In consultation with Christophe, I therefore propose that we extend the
>> > TAP RFC to 25th September to allow the above details to come together.
>> 
>> Last two days, last issue from rfc page:
>> 
>> In the current spec, there are two resources under the base URL and VOSI 
>> are
>> accessed via one of them:
>> 
>> async
>> sync
>> sync?REQUEST=getAvailability
>> sync?REQUEST=getCapabilities
>> sync?REQUEST=getTableMetadata
>> 
>> There is a proposal to access VOSI as resources off the base URL (more pure
>> REST style vs standard DAL REQUEST param). The motivation is to move VOSI 
>> out
>> from under sync so that both async and sync could be made optional (both
>> required in PR). The new resource structure would be:
>> 
>> async
>> sync
>> availability
>> capabilities
>> tableMetadata
>> 
>> We have had many discussions on this topic, made compromises all around, 
>> and
>> never reached a unanimous agreement. There are good reasons for both
>> approaches. The current draft is consistent with DAL style as embodied in
>> SSA1. The proposed makes it cleanly possible to have optional async/sync
>> execution of jobs (currently we require both, but we could relax this in a
>> future version of TAP very easily if needed).
>> 
>> To be very clear: both of these work fine, so there is nothing broken and 
>> to be
>> fixed. This is a stylistic issue (RPC vs REST) and about making plausible
>> future changes as easy and painless as possible. Given that, I don't see 
>> any
>> point in dredging up all the arguments again.
>> 
>> The crude WG concensus is that more people favour using resources over the
>> REQUEST parameters, but I would like to call a vote to verify that and will
>> change the draft to match the WG decision. If you care, please respond to 
>> this
>> message and chose one of:
>> 
>> use REQUEST parameter
>> 
>> use resources
>> 
>> I will tally and start rewriting on Monday (28th).
>> 
>> -- 
>> 
>> 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
>
>