Re: [wcsplus] asynchronous response

Hi again,

Dominic Lowe wrote:
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

For the last option, I think the response can be more extensive than just returning a URI. An HTTP "202 Accepted" response can have a body and the spec suggests it

   "SHOULD include an indication of the request's current status and
   either a pointer to a status monitor or some estimate of when the
   user can expect the request to be fulfilled".

I would see the "status monitor" as similar to your "pollable" URI.

I think we need to come up with an XML encoding of the body of a 202 response and the response from the "pollable" URI. This is where I wonder if SOAP/WS-* work in this area might be useful to look at.

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

That's a good idea. Just return the manifest if the data is ready.

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?

Yes, sounds good.

Dominic

*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.

I agree.

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