TAP 1.0: sync vs async

[Douglas Tody]

Hi -

As Guy says we already had this discussion some time ago and agreed
upon the approach currently in the document (now also the basis for our
planning for SIAV2 and other DAL interfaces).  It would be unfortunate
to reopen all these issues again at this point in the process.

Unfortunately people have different models for how these things
should work.  One is better than the other in some cases, but in the
end it does not make all that much difference, we just need to be
consistent and pick the best compromise to satisfy all our use cases.

We considered having only ?baseURL and ?baseURL/async (for all
operations not just VOSI).  I actually preferred this but others
argued for symmetry with ?baseURL/sync and ?baseURL/async, which
is a reasonable scheme as well.  Whatever we do we do not want to
make a special case for this service operation rather than that one.
To a client application getCapabilities is a service operation just
as much as eg queryData.  They should be provided in the same way.
We should be able to just compose the URL with a standard pattern with
no special cases.  Providing direct access to a static file as Guy
suggests is something we want to enable, but this is easy to provide
with any of these schemes, and it is nice to have a scheme which can
also enable dynamic generation of the Capabilities, table metadata,
or whatever from more fundamental metadata.  What we have now works
for all of these use cases.   I could go on - this is a brief rehash
of the earlier discussions.

 	- Doug


On Thu, 16 Jul 2009, Guy Rixon wrote:

> Hi Gerard,
>
> I support your suggestion that the VOSI resources be siblings of the TAP sync 
> and async resources.
>
> This was discussed at length in the drafting of TAP 0.3x, but the editors did 
> not get a consensus in favour, only a majority.
>
> Separating the VOSI resources has an important advantage: the capabilities 
> and tables resources can then be implemented as a static XML-document. When 
> VOSI is combined with the TAP-query resources, requests for capabilities and 
> tables have to be generated (or at least mediated) by servlets or scripts.
>
> I note that the VOSI spec doesn't mandate any particular URL for the VOSI 
> resources. Including them in sync is allowed; separating them is also OK.
>
> Cheers,
> Guy
>
> On 16 Jul 2009, at 10:24, Gerard wrote:
>
>> Dear colleagues
>> 
>> In the recent interop the issue of whether support for synchronous queries
>> should be mandated, or async, or both was mentioned, but not really
>> discussed further in the relevant sessions. I would like to once more bring
>> this up though.
>> 
>> My proposal is still that we mandate that sync OR async is supported, or
>> both.
>> 
>> There are use cases where sync allone suffices, and whatever some experts
>> argue, sync is easier to support in a robust manner than async.
>> On the other hand there are use cases where async is clearly the best
>> option, and sync might never be desired, so async alone should also be
>> possible.
>> We have had discussions on the mailing lists some months ago and I guess we
>> do not need to rehash those.
>> 
>> One "argument" against leaving it optional to support sync is that the VOSI
>> requests are currently implemented on the sync/ end point.
>> Irrespective of how we decide on sync vs async, I propose the VOSI requests
>> should NOT be put on top of the sync/ end point, but "next to" sync/ and
>> async/. They are different things from the actual service requests and
>> should/need not be mixed with them.
>> 
>> All these points were discussed with various people right after the closing
>> of the interop, when I realised that they had not been discussed.
>> There was general agreement (about 8 people were included in the 
>> discussion,
>> I will keep their identities secret) on all these points.
>> I promised to bring this up during the RFC, so here you have it.
>> 
>> Best regards
>> 
>> Gerard