TAP 1.0: sync vs async
paul.harrison at manchester.ac.uk
Fri Jul 17 07:59:21 PDT 2009
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 -
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.
More information about the dal