NOTE: The wcsplus mailing list is no longer active. The list archives are made available for historical reasons.
Hi Ethan,
One case that seems important to me but is not satisfied by the above is when the client would prefer the data returned synchronously but still wants the data even if the server can't return it till later. Or should that be handled by a combination of the above? Which makes me think that some kind of negotiation is needed. For instance, what about the client that wants the data now or within an hour but doesn't want it if it will take a day.
I think negotiation could potentially be important, but I'm not sure this is a feature for a first cut, especially if we're doing this in limited time (Ben D. has already said in a different email that there are concerns about whether async operation can be implemented in time). The main practical issue here is that it's very difficult for a server to give an accurate estimate of how long a job will take. It would certainly be possible to create such a mechanism but I think this would need a *lot* of experimentation and thought. It's a perfectly valid requirement but I would prefer to see some evidence that this is really needed because I think it's going to be hard. Regarding my concerns about HTTP response codes and REST to marshal the conversation on asynchronous behaviour. Again, I think this is a perfectly valid approach and my concerns aren't too critical, but my nagging doubts are: 1) In my experience, http response codes are often not used well by servers and clients. It's fine to include them in a spec, but I would prefer to ensure that the information they carry is duplicated in any XML response, so clients don't have to infer too much from the response code. (E.g. it's fine to specify that a server should respond with 202 ACCEPTED, but there should also be an XML document giving more information. Maybe that's what you were saying anyway.) 2) Do we need redirects at all? I'm not sure that we do, if we follow the WPS method of embedding URLs to data objects in the XML response. 3) My concern over REST is that none of the OGC specs (to my knowledge) follow REST principles and I think it's more important to follow the OGC conventions than apply a new paradigm. In the real world you can only rely on clients knowing how to do a GET and POST (PUT and DELETE are poorly supported, e.g. in Ajax-style operations. But perhaps you weren't considering using PUT or DELETE anyway). One of the very nice things about the existing OGC specs is that I can get data, images etc directly through a web browser and it helps the community to develop nifty web applications (like OpenLayers). Hope this helps. I agree completely that the top priority is a clear spec, but we do have to make sure that it's easy to implement properly. I guess that's the point of interop experiments! Cheers, Jon -- -------------------------------------------------------------- Dr Jon Blower Tel: +44 118 378 5213 (direct line) Technical Director Tel: +44 118 378 8741 (ESSC) Reading e-Science Centre Fax: +44 118 378 6413 ESSC Email: jdb@xxxxxxxxxxxxxxxxxxxx University of Reading 3 Earley Gate Reading RG6 6AL, UK --------------------------------------------------------------
wcsplus archives: