TAP RFC [VOSI]

[Keith Noddle]

I favour using resources. It is the way the IVOA is heading (for good 
reasons) and it would a shame to restrict ourselves to decisions taken 
within the DAL WG before the current scheme really started to emerge.

That said, it would be madness to invalidate an existing class of 
applications that assume REQUEST style access. How about we define both 
access styles in TAP V1.0, but deprecate REQUEST from the start? That 
way TAP (and other DAL standards) can adopt IVOA-wide approaches in the 
future without negating existing efforts in the short-to-medium term. 
Although viewed from a purely standards based perspective deprecating 
something in a V1.0 spec seems crazy, we have to take account of legacy 
issues. Just a thought.

Keith.

P.S. It's not clear to me how many client applications would be 
adversely affected. Anyone have any numbers? We have to get the balance 
right between extra effort on the part of server-side engineering 
(supporting both) versus client-side engineering (changing to meet new 
requirements).


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



-- 
Keith Noddle                    Phone:  +44 (0)116 223 1894
AstroGrid Project manager       Fax:    +44 (0)116 252 3311
Dept of Physics & Astronomy     Mobile: +44 (0)7721 926 461
University of Leicester         Skype:  keithnoddle
Leicester                       Email:  ktn at star.le.ac.uk
LE1 7RH, UK                     Web:    http://www.astrogrid.org