making TAP /async optional.

[Petr Skoda]

> The /async mode is justified by the necessity of enabling TAP servers to 
> process queries consuming a lot of time or resources. The problem is that the 
> decision of using one mode or another is taken on the client/user side. That 
> supposes the client or the user to have an idea about the resources taken by 
> the query or simply to be aware about that issue.

I think the user should be warned first that the sync queries will time 
out soon after xx seconds - should be in description of TAP service 
clearly stated.

And that async will run for a longer time - but still limited by server
The UWS of the TAP service should say directly what is the timeout to 
abort the job.

so the user can try the sync - as it is natural for him  -  he is 
accustomed to wait after http query some seconds.
When he did not get answer - he should realize his query is time-demanding 
and EITHER to think it over and create more focused  query
OR select /async knowing it will run up to XXX minutes bringing the 
discomfort of checking the status (but he may get results by mail as well)



> Taphandle works around that issue by hiding this choice. It always using the 
> /async mode (when it is supported). If the requested data comes within 10sec 
> it is displayed as if the query was processed in /sync mode.
> In my opinion, the choice of the sync mode should be under the responsibility 
> of the server which would just have to notify the client that its job has 
> been switched in /async mode (only concerning servers implementing such an 
> advanced feature).

this is interesting solution (I did not notice it in querying my tables)
but DO YOU THINK the overhead connected with whole UWS stuff - creating 
processes and controlling it, maintaining list of running instances (what 
about autorization )  is not bigger then simple  sync query ?
I am just guessing the /async is an overkill to short instantenous queries 
.....

But maybe I am wrong and the demands are about the same



> A possible evolution of TAP could be to support a third sync mode /autosync 
> (no better name comes) which would behave exactly as /sync for servers not 
> supporting asynchronous processing or for queries responding quickly.

the same argument as above for autosync

Petr

*************************************************************************
*  Petr Skoda                         Phone : +420-323-649201, ext. 361 *
*  Stellar Department                         +420-323-620361           *
*  Astronomical Institute AS CR       Fax   : +420-323-620250           *
*  251 65 Ondrejov                    e-mail: skoda at sunstel.asu.cas.cz  *
*  Czech Republic                                                       *
*************************************************************************