making TAP /async optional.

[Paul Harrison]

On 2014-05 -19, at 17:35, Laurent MICHEL <laurent.michel at astro.unistra.fr> wrote:

> Hello,
> 
> I'd like to come back to Markus's point about the necessity (or not) of keeping the /async mode mandatory in TAP.
> 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.
> Considering that even query engines hardly manage to predict the order of magnitude of the query processing duration, I believe that giving the choice to users is not really helpful.
> 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).
> 
> 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. Otherwise, when a job is processed in /async mode, the query response would be similar to that specified by the actual  /async mode.
> The impact for the client would be limited. It would just have to distinguish responses containing data from responses containing the description of an /async job (to be defined).
> Both /sync and /autosync would be mandatory.
> 


I think that you are correct that it is not easy for the client to make the choice between using the synchronous and asynchronous modes  - The UWS specification had a pattern for implementing a synchronous service on top of an asynchronous basis - which is similar to your /autosync suggestion http://www.ivoa.net/documents/UWS/20101010/REC-UWS-1.0-20101010.html#SynchronousService - The main difference is the UWS spec effectively says that what you called /autosync should be the default implementation of /sync.

I think that mandating the synchronous mode have the suggested implementation (via the async endpoint) does allow a client that understands that there is an asynchronous way to get the data always to make a query to the same /sync endpoint - and if it does not obtain an answer in a suitable time, can use the returned redirection URL to use all the asynchronous mechanisms on a query that will already be running if it desires.

This suggestion means that the client does not have to make an arbitrary choice before the query is made, however, it basically means that all service implementations must support asynchronous operation anyway, which does not suit the people who are calling for “simpler” server side implementations as their motivation for dropping async.

Regards,
	Paul.