NOTE: The wcsplus mailing list is no longer active. The list archives are made available for historical reasons.
Hi Stefano, Stefano Nativi wrote:
Hi Ethan, Sorry for the delay of my answer; I had to prepare my term in Padua. I try to answer inline.I agree "Asynchronous Access" is not very clear. "Store" is much clearer. Does "Persistent Storage" add some specific meaning for you to "storage"?We used the term "persistent" to express the storage capability to last a certain time period allowing more than one download. Perhaps, "persistent" is too strong.
I think "storage" already implies keeping items for some amount of time. Is the key point for you the time period it is stored ("persistent", or "long-term"?), that it doesn't go away after the first access (?), or that more than one client can request the stored data ("shared storage"?).
I agree that "Push" capabilities might be handy. However, I think it is loaded with difficulties. The main issue is that there will be many firewall issues to get around on the client side. Most firewalls are setup to allow outgoing HTTP requests and incoming responses but not incoming requests. The other issue is that it means a client needs to also be an HTTP server so it can accept HTTP POST requests. If there are a lot of clients trying to receive PUSH responses, we are back to the firewall which may only have one or two machines each with one or two ports open for HTTP. There are ways to deal with all these issues (e.g., you mention the possibility of an upload server (proxy?) that then deals with the client) but all the PUSH issue adds a lot of complexity to the already quite complex asynchronous issue. Because of this, I think we (WCS 1.0+) should skip the PUSH issue for now.First of all, we agree that the "push" approach should be avoided for now.As for your comment, it is possible to use a proxy application server to avoid the firewall issue.
Agreed on both counts.
One comment on the response codes, I think we should use the 201 (Created) HTTP response code rather than 302 (Found) for the immediate/store case. I think the meaning of the 201 code (the request has caused a new resource to be created and it can be found at the given URI) more closely matches this case than the meaning of the 302 code (the resource is not at the request URI but can be found at the given redirect URI). A subtle difference perhaps but I think it is important to be careful that our mapping matches the standard meaning of the HTTP response codes.Actually there's a subtle diversity, here; it mainly depends on the used interface. Let's consider the following use cases:a) case where to use "302 Found" with Location: U2 > I send to U1 URI a GET request to retrieve the U1 resource > the U1 resource representation is available at URI U2> the authoritative address of the resource is still U1 (clients must send their following requests to U1 URI)b) case where to use "201 Create" with Location: U2 > I send to U1 URI a POST request for creating a new resource U2 > the created U2 resource is available at U2 URI> the authoritative address of the resource is U2 (clients must send their following GET requests to U2 URI)In summary, a GET request should be used to retrieve a "representation" of an existing resource; while, POST is used to "create" a new resource along with its authoritative address.
That is a pretty strict interpretation of the line between resource and representation and between GET and POST. Since a WCS response can be a quite complex (possibly never to be repeated) "representation" of a resource (subset, remap, interpolate, etc), I really think of each one as a new resource rather than a representation.
Also, for a stored WCS response, clients should be able to share the resulting URI with others and access it multiple times. The HTTP spec is very clear that the 302 response should not be cached or used multiple times, that any repeated access should go to the original URI.
So, I still feel that 201 is a more appropriate fit for this case.
I don't understand your delayed/non-stored/pull case. Isn't it implicitly the same as the delay/store/pull? The server starts processing on the first request, ignores any requests till it is done, and once finished stores the data till it is requested again. Why not use the 202 response to send information about when to check again and all the other stuff recommended as content in the 202 response body.The difference is about the redirection aspect: a) delayed/non-stored/pull case: > client requests U1 resource > server returns the 202 Accept (with status ?) > ..... > client requests U1 resource > server returns the 200 OK with the resource representation > /following requests requires the entire processing, again. /b) delayed/stored/pull case: > client requests U1 resource > server returns the 302 Found with Location: U2 > client requests U2 resource > server returns the 202 Accept (with status ?) > ..... > client requests U2 resource > server returns the 200 OK with the resource representation> /following requests may be directed to U2, accessing the existing resource representation (persistent store)./
I'm still not sure I understand. What happens if two users make the same request around the same time? Does the server have to do the same processing twice? Why would anyone prefer the delayed/non-stored/pull case over delayed/stored/pull?
Ah ha. Upon re-reading the "202 Accept" section of the HTTP spec, I realize that there is nothing in the spec that says anything about the results of the accepted processing. The 202 response seems to have been targeted only at requests for processing where knowing it has been completed is all that is important. Not, as I have interpreted it, that processing is done and may have resulted in a new resource (all encoded in the body of the response or the results of a status monitor). I think our interpretation of the 202 response is the root of the difference in some of our responses.
Though I still find the 202 response the cleanest mapping to an asynchronous response. Whether the accepted processing results in an externally accessible artifact or not, the 202 response seems to capture what is going on. It is up to the body of the 202 response and any response to the "status monitor" to communicate information about any artifacts of the accepted processing.
//In my opinion, this discussion and the related documentation is very interesting and I'd like to consolidate it in an OGC discussion paper. What do you think? Who is interested in co-authoring this document?
I'm not familiar with OGC discussion papers but I'm ok with consolidating the discussion for review by others outside the WCS 1.0.0+ group.
Ethan
--Stefano
-- 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: