Hi all,
As promised, yet another email.
There are three areas of the asynchronous response (store/delay) issue I
think we need to look at:
1) Communicating the server capabilities to the client.
2) Communicating what the client can/will/wants to accept from the server.
3) Responses: type of response and content.
-----
For Server capabilities, I came up with 3 or 4 capability types and how
to encode those in terms of both store/allowAsync parameters and just
the store parameter:
1) The server has full store/delay functionality
a) store= {true|false}; allowAsync={true|false}
[NOTE having dropped PUSH, does "store=F, allowAsync=T" make
sense? And how do we handle that?]
b) store={true|false|serverdecide}
Dominic felt "false" and "serverdecide" didn't make sense
together (or was it just those two with out "true"). I think
this combination actually captures the "allowAsync" parameter
very well. "false" doesn't allow async, "serverdecide" does
allow async.
2) Server can store data but not asynchronous
a) store={true|false}; allowAsync={false}
b) store={true|false}
3) Server can't store data and can't do asynchronous responses
a) store={false}; allowAsync={false}
b)store={false}
4) Server can store data but only asynchronous (???Is there any use case
for this?)
-----
Here are the types of client request I came up with (again with possible
store/allowAsync and store encodings):
1) Client wants data returned without delay.
a) store= {false}; allowAsync={false}
b) store={false}
2) Client wants data created now and stored.
a) store= {true}; allowAsync={false}
b) store={true}
3) Client wants data now or later but store it either way. (* What if
delay is longer than client wants to wait?)
a) store= {true}; allowAsync={true}
b) store={serverDecide}
4) Client wants data: if now, don't store; if later, store. (* What if
delay is longer than client wants to wait?)
a) store={?}; allowAsync={true?}
b) store= {serverDecide?}
5) Client wants data delayed and stored only (?? Is there a use case for
this? Any reason client should want delay?)
6) Client wants an estimate on how long request will take before making
request.
Same as 3) and 4), would HTTP HEAD request work? No. You only get
back HTTP header fields and the estimate infor would be in the body
of the response not the headers.
Could change "allowAsync" to "async" (or "delay") and change the
values from "true" and "false" to "allow", "ban", and "estimate".
-----
Allowed responses:
For request type 1 (return now):
a) 200 OK - response body contains data.
For request type 2 (create now and store):
a) 201 Created - Location header contains new URI and body contains
XML coverage/manifest with link to new URI.
For request type 3 (store, now or later):
a) 201 Created - (see 201 above)
b) 202 Accept - body contains XML encoding of current status, URI to
check status, URI to get data once ready, estimate of when it will
be ready (and length it will be on server? or is this status
information?)
For request type 4 (if now, don't store; if later, store):
a) 200 OK - (see 200 above)
b) 202 Accept - (see 202 above)
For request type 5 (): ???
For request type 6 (want estimate of delay):
a) 200 OK - XML encoding estimate (subset of XML for 202 response?)
Other responses that clients should support:
Redirects
301 Moved Permanently
302 Found
307 Temporary Redirect
Client errors
400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
Server errors
500 Internal server error
-----
Sorry to ramble on about this. Kind of a brain dump. I'm hoping to stop
thinking about this for awhile and write some code ;-).
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/
---------------------------------------------------------------------------
