TAP RFC [VOSI]

[Doug Tody]

Hi Pat -

Since both of these approaches will work anyway, it would be a
shame to have TAP be inconsistent with the other DAL interfaces
in terms of how service requests are posed.  In effect we would be
reversing decisions already made within the DAL WG in defining how
these interfaces are composed.  While the pure REST approach has
its place (process/job status a la /proc and virtual file storage
are obvious cases that fit the model well), the DAL interfaces are
fundamentally object oriented with complex operations which can be
defined independently of the transport protocol, and the RPC model
with logical operations is the better fit in this case.  What we
already have in the TAP proposal now is a good pragmatic compromise
to be able to employ both models within the same interface.

The proposal here would not only be inconsistent with decisions already
reached within the DAL WG, it would require reversing what we already
have worked out in months of painful discussions for the current TAP
draft specification.  There are good arguments to not make this change.
Hence I suggest we stick with what we have already agreed upon.

 	- Doug


On Thu, 24 Sep 2009, 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).
>
>