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>
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 3HJReceived on 2006-11-01Z12:11:12