TAP RFC [VOSI]

[Alberto Micol]

Dear Doug,

Before casting my vote, I'd like to understand better the issue you  
mentioned.
So far SSA has "reserved" the various operations, including  
getCapabilities,
which means that such operation (though depicted in the SSA) is not  
yet in use.
Hence, formally, there is no risk of compromising existing operational  
services by choosing "resources" instead of "requests".

Currently used REQUEST's values (in SSA) are: getData and queryData.
REQUEST is therefore used to specify REAL operations on the data.

getCapabilities, getAvailability, getTableMetadata are (or, better,  
will be) META (so to say) operations.


REAL REQUESTs could be posed in sync or async mode.
META operations are just meta operations that immediately return  
something (META+async not foreseen).


In the above-mentioned context, could you please elaborate more on  
this sentence:
>> 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.

I do not appreciate the risk you are alerting us about, hence I'd like  
to hear more about it.
Are you mentioning a real substantial problem or is it "just" that is  
not nice to break the symmetry?

(Little parenthesis that adds to my confusion regarding all this:
  I never understood why it is up to the client to specify sync or  
async;
how can the client know in advance if a query CAN be answered quickly  
by a given server? IT CAN NOT!
I would think it is up to the server to decide whether to provide back  
a sync or async response.
Sync and async should hence be output parameters, not input. )

Many thanks for any clarification,
Alberto


On 24 Sep 2009, at 19:14, Doug Tody wrote:

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