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