TAP 1.0: sync vs async

[Douglas Tody]

On Fri, 17 Jul 2009, Paul Harrison wrote:

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

TAP drafts have been out there since at least the fall of last year.

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

But REQUEST,VERSION is the standard for how we represent service
operations on top of a simple HTTP protocol.  Knowing the baseURL and
the operation name one can uniformly construct the URL.

That is how it works in the DAL interfaces, and has worked for several
years now - there was an opportunity to speak up on this at least 3-4
years ago.  We adopted this from OpenGIS which is the same.  It works
very well, is quite clear and simple to understand, is not HTTP (or
SOAP etc.) specific, and has been in use for years in both OpenGIS
and VO with no issues.  It is hard to promote any alternative which
is more than a mere preference in style of interface.   If you want
to argue REST (essentially the Unix file model mapped to the Web) vs
object oriented, well OO will win for most service objects, and will
be closer to 99.9% of the stuff out there currently in the real world.

Guys, I really don't want to have this argument again for the Nth time.
How about we finish this version of DAL so that we can build some
apps for the users who pay for all this, and you guys can then go
off and do DAL3?

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

Obviously, SSA is the first of these.  What TAP has added is the
pattern for how we do async as well as sync (which is great to have).

 	- Doug