TAP 1.0: sync vs async

[Paul Harrison]

On 2009-07 -17, at 14:27, Douglas Tody wrote:

> Hi All -
>
> What mostly bothers me about this discussion is that not only did we
> (some of us anyway) already discuss this some months ago and reach a
> workable agreement, but we were supposedly to go to RFC on TAP earlier
> this month, and here we are with folks now proposing fundamental
> changes to the basic service interface.  At some point, unless an
> actual serious problem is found we need to stand by our decisions
> and agreements and move on to have a usable interface.

On the other hand the whole point of the RFC period is as a time for  
people who have not been involved in the discussions to be able to  
comment - it might well be that some of these discussions have  
happened, but it seems to me that they did not necessarily all appear  
in public on the mailing lists.

>
> A second issue is the impact of a change such as you are proposing.
> Not only is the current TAP spec (and all versions for nearly the
> past year) using the current interface model, but also the SSA Rec has
> long mentioned getCapabilities as a service operation, and the draft

there is nothing in this proposal to say that getCapabilities is not a  
"service operation" - just that it be on a different URL -

i.e.

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

This is instead of using the REQUEST parameter, which is no longer  
needed with the above endpoints (names being just my invention for now)


> SIAV2 interface we are currently preparing adheres to this model.
> It is not just TAP which is the concern here; we need to have a high
> level of consistency among all these services.

As TAP is the first of these, that is precisely why people are keen to  
make sure that  the pattern is the

> The current interface
> profile works both for the logical service-with-operations model,
> as well as for the more HTTP-specific resource model, and is also
> VOSI compliant.  Sync/async/UWS are all adequately supported.  It may
> not be ideal for each model but it is not bad.  The alternative which
> has been proposed does not support all models and we would no longer
> be able to consistently describe the service as a logical interface
> composed as a set of service operations.
>
The alternative does do this, and several people in this thread  
believe it does so in a cleaner fashion, because you do not have to go  
into detail about how if you have an asynchronous only service, the  
"getCapabilities" operation is actually synchronous on the endpoint  
that otherwise is asynchronous.

To be honest at the moment in the TAP draft there is the odd mixture  
of having service operations partly specified on different endpoints  
and partly by the REQUEST parameter - it would be better to do either  
all on different endpoints as proposed here or all on the same  
endpoint with the REQUEST parameter determining the operation.


Cheers,
	Paul.