NOTE: The wcsplus mailing list is no longer active. The list archives are made available for historical reasons.
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/ ---------------------------------------------------------------------------
wcsplus archives: