Re: [wcsplus] asynchronous response

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

Hi Ethan,

(still not fully digested your brain dump..) I'm also finding it useful to think of this in terms of the behaviour of the client and server.

I think the wcs server can:
        return data
        return an XML manifest pointing to stored data.
        return a "pollable" URI

The service at the pollable URI* can:
        return some sort of status message (e.g. not ready)
return an XML manifest pointing to stored data
A full 1.0.0 + client can:
        call GetCoverage
        call a Polling service
        get data from a URI

Does that match your view of things?


*The polling service and 'the wcs server' may be one and the same thing, but it's maybe useful to separate them for this discussion.

On Friday 05 October 2007 21:15, Ethan Davis wrote:
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}

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

    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

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:

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 ;-).


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