Re: [wcsplus] asynchronous response [was: Re: WCS 1.0+]

Hi Ethan, all,

I think you're right that the extra parameter is likely to be unpopular... I am 
wondering if it can be avoided. An alternative idea may be to allow the 'store' 
parameter to accept a range of values, not just true/false.

i.e. something like:
store=true
store=false
store=serverdecide

So in this case the responses are:

1) store=true: Asynchronous response or error if server does not support 
asynchronous response
2) store=false: Synchronous response or error if request is deemed by the 
server to be too large for synchronous response. Or error if synchronous 
response not supported (as per Stefano's change request).
3) store=serverdecide: Same as your client requesting AllowAsync=true. i.e. 
server responds with either asynchronous or synchronous response, or error 
saying that 'serverdecide' is not supported.


If you want all the control to be at the server then you could specify that the 
server only supports 'serverdecide' and that the default is 'serverdecide', 
thus giving the client no choice. Likewise if you want the client to have all 
the control you can specify that the server supports 'true' and 'false'. I 
think the only nonsensical combination would be to specify that the server 
supports 'serverdecide' and 'false'.


Cheers

Dominic




-----Original Message-----
From: wcsplus-bounces@xxxxxxxxxxxxxxxx on behalf of Ethan Davis
Sent: Wed 03/10/2007 19:04
To: wcsplus@xxxxxxxxxxxxxxxx
Subject: [wcsplus] asynchronous response [was: Re: WCS 1.0+]
 
Hi Stefano, all,

Yes, asynchronous response is part of WCS 1.0+ so I'm including your CR 
doc in this email.


John and I talked about asynchronous responses a bit the other day. 
Below are a few thoughts from our discussion (all of which are based in 
the REST/ROA realm rather than the SOAP/WS-* realm). I was going to 
suggest we continue this conversation but postpone implementation in WCS 
1.0+ until later in the process. But with this CR being submitted, maybe 
it is worth moving forward sooner rather than later. Thoughts?

Use cases:
1) "Asynchronous Access" - The client wants the data stored for access 
in future step of chaining or some such.
2) "Asynchronous Response" - The server determines that it will take 
time to process and respond so wants to let client know to come back and 
get the data later.

Does anyone have more concrete use cases of the "Asynchronous Response" 
type? Jeremy, Bruce, this was on your list. What is(are) your use case(s)?

Negotiation:
1) For the "Asynchronous Access" use case, I think the current way a WCS 
server lets the client know that it can "store" the data is fine (i.e., 
AllowedValues: "True", "False").

2) For the "Asynchronous Response" use case, the client needs 1) a way 
to know if the server might make an asynchronous response and 2) a way 
to indicate to the server that it wants a request fulfilled even if it 
is as an asynchronous response. Perhaps "AllowAsync". So the server 
indicates that it might do an asynchronous response by specifying the 
"AllowAsync" parameter with AllowedValues of "True" and "False", similar 
to the "store" parameter.

I'm guessing the WCS.RWG won't like the extra parameter as they seem to 
lean towards simplicity by reduction of parameters. But I don't see a 
good way to handle both the use cases above without a parameter for each 
of the above use cases (e.g., "store" and "AllowAsync").

Response:

For the "Asynchronous Access" use case, I think what the WCS has now 
seems fine except I would like to specify that the HTTP response code 
will be a 201 (Created). I assume the body is already defined as a XML 
coverage/manifest containing URLs to the data.

For the "Asynchronous Response" use case: If the client leaves out 
"AllowAsync" from their request, the server must either respond 
synchronously or with an exception that points to missing parameter 
"AllowAsync". If the client specifies "allowAsync=False", the server 
must either respond synchronously or with an exception pointing to a bad 
parameter value in "AllowAsync". If the client specifies 
"allowAsync=True", the server may respond synchronously or 
asynchronously. Where the asynchronous response would be an HTTP 
response code of 202 (Accepted). As the CR discusses, the body of the 
response should contain some indication of current status, some way to 
monitor the status, and an estimate of when it will be done. Should the 
CR include some suggestions for XML encoding of this information? I'm 
sure there are examples of this kind of thing in the SOAP/WS-* realm but 
I'm not familiar with that.

Ethan

-- 
Ethan R. Davis                                Telephone: (303) 497-8155
Software Engineer                             Fax:       (303) 497-8690
UCAR Unidata Program Center                   E-mail:    edavis@xxxxxxxx
P.O. Box 3000
Boulder, CO  80307-3000                       http://www.unidata.ucar.edu/
---------------------------------------------------------------------------