Update on things to follow

[Kona Andrews]

 Hi all,

> For something like SIA, queryData is always synchronous, and getData
> is synchronous, and if it will take a long time to generate the data,
> the data staging operations would be used and you have a stateful service.
> But one can still come in at the end and get the data with a synchronous
> operation.
> 

I would be perfectly happy to see all the synchronous calls be 
pure HTTP-GET (or POST if absolutely required).  I would also like to
see all the calls being synchronous;  it would certainly be nice if TAP 
could be driven, at least in principle, from an ordinary web browser.

> Ideally the interface should be structured to make simple queries
> simple synchronous operations, with the ability to handle large
> long running queries an advanced capability which simple service
> implementations need not support.
><snip>
> Yes, unless it is a long running operation and we need to stage data
> in a VOStore.

There presumably needs to be some distinction in the way that
synchronous ("short") vs asynchronous ("long-running") calls are 
set in progress by the client.  

I would propose that the simplest way to implement staged (asynch)
queries is to allow an optional parameter on the HTTP-GET query
interface, which is simply an IVORN specifying a destination location
in the invoking user's VOStore storage.  If this parameter is present,
results go to the specified location in the user's VOStore; if not, 
they come back to the client.  The client knows what to expect based 
on what parameters it submitted; the actual query invocation is still 
a simple synchronous operation.

This allows clients to have results returned out-of-band, and places 
the responsibility for providing/managing the storage of results data 
where it ought to be placed - with the consumer of that data, rather
than with the data service provider.  I would hope that the VOStore 
interfaces (rather than the data service) might be able to provide feedback 
to the client about whether the data transfer is complete or not (certainly 
at the most basic level, the user can just monitor the size of the destination 
file in their VOStore).  This means that TAP would not have to provide
complex stateful services for monitoring and managing queries - something
that is provided by, and arguably better left to, the more advanced SOAP
data service interfaces such as UWS.

> Exactly how this should look for TAP is not yet clear since for
> TAP a data query can be a long running operation.  Most TAP queries
> however (>90% ?) are probably simple synchronous queries as well,
> especially if we have a way to page through a large query response with
> a succession of calls, something which all queries probably require.

I would be loath to start putting functionality such as paging of results
into TAP;   I really think we should keep it as simple as possible
(think conesearch-simple).  If there are a lot of results, let the user 
choose to have them delivered to their VOStore, and then view/manage 
them using the panoply of regular data analysis tools available.  
If TAP starts to get bloated with functionality, it becomes far less
attractive to imlement it alongside the richer asynchronous SOAP interfaces 
we already implement.

All the best,
Kona.
-- 
Kona Andrews        kea at roe.ac.uk
AstroGrid Project   http://www.astrogrid.org
IfA, Royal Observatory, Blackford Hill, Edinburgh EH9 3HJ