TAP 1.0: sync vs async

[Douglas Tody]

Hi All -

I agree with Gerard that async should not be mandated for any of these
services - yes there are cases where it needed, but there are also
many cases where the data being served and functionality provided
are quite constrained and async capabilties are really not an issue.
The cost/benefit argument is not sufficient.  The VOSI queries are an
obvious example of this but it is true for many data services as well.

But our position for some time now is that we will not hold up
the whole TAP effort if people cannot agree to this point of view.
Some other way will likely be found to solve this problem.

I am not enthusiastic about splitting this into separate Capabilities.
Capabilities should correspond to service interfaces (e.g., TAP, SCS).
We do not want two separate TAP interfaces.  Rather we just need to
describe the capabilities of the TAP service.  It is vital that we
have a simple way in the registry interfaces to search for services
based upon their capabilities.  By that I do not mean merely whether
they support a certain type of interface (Capability), but whether
they support significant real capabilities defined by that interface.
The sync/async issue is only one example of this.  Archival vs cutout,
2D vs ND, etc. (many others) are similar issues as well.  We do not
want a solution which leads us to classify all these as separate
Capabilities (interfaces) rather than capabilities (features of a
service interface).

 	- Doug


On Thu, 16 Jul 2009, Gerard wrote:

> Hi Paul
>> I also support this idea - in fact I would go further (as
>> also recently suggested by Tom) and say that the sync and
>> async should also be registered as separate Capabilities, and
>> thus potentially on totally separate machines, rather than
>> being forced into the single URL tree.
>>
> I agree, this was missing in the proposal.
> It would be good to be able to find out explicitly from service metadata
> whether one can send sync and/or async queries.
>
> Gerard
>