[wcsplus] asynchronous response

NOTE: The wcsplus mailing list is no longer active. The list archives are made available for historical reasons.

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/
---------------------------------------------------------------------------




  • 2007 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the wcsplus archives: