TAP 1.0: sync vs async

[Paul Harrison]

Hi,

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.

This would also make it easier to support async calls to a sync only  
implementation (if this were allowed) by installing a standardized UWS  
proxy component which could "convert" the synchronous behaviour into   
standard UWS asynchonous. The astrogrid CEA implementation already has  
a mode of operation ("HTTP applications") which would make it suitable  
to act as such a proxy.

Cheers,		
	Paul.


On 2009-07 -16, at 10:33, 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
>

Dr. Paul Harrison
JBCA, Manchester University
http://www.manchester.ac.uk/jodrellbank