NOTE: The wcsplus mailing list is no longer active. The list archives are made available for historical reasons.
Dear Stefano, Thanks for this. I haven't had time to digest it fully but I have these main points at this stage: 1) Regarding the "push" architecture. I think this is really interesting and valuable to consider. However, I am not sure how widely this architecture would be adopted in the real world due to the fact that it would require clients to have incoming firewall ports open - this is something that most clients, especially commercial clients, are currently reluctant to do. (This is why we took the polling approach in DEWS.) This is certainly a known issue that the Grid community have found with asynchronous callbacks of this type. 2) For asynchronous access, the document says that the client will repeatedly make the data request (using the full URL) until the data are ready. This requires that the server recognises that each repeat request is identical to the first. Is it not better for the server to respond with a "job ID" or similar that the client can use to poll for updates? This would be much simpler to implement on the server side, and also makes it much easier to distinguish between new data requests and requests for updates. 3) I don't understand what the value of the Use Case "asynchronous access without storage" is. The only difference I can see between this case and the case of "asynchronous access with storage" is that the data would be deleted by the server as soon as the client has downloaded it. Is this what is intended? In both cases, the server has to extract the data in a background process and put the data into temporary storage, waiting for the next request from the client. 4) "While OWS POX binding is not a RESTful implementation it is still implicitly resource-oriented since it is based on a uniform interface (getSomething) on different resources (capabilities, descriptions, coverages, features, etc.)." I see what you are saying here, but I still see OWS as being query-oriented (the query is the important part of the protocol, not the data payload). Queries are not CRUD operations in the usual sense. Yes, OWS is based on access to resources but in fact there are an *infinite* number of possible resources (coverage subsets, feature subsets, etc). As I said in a previous email the REST approach might improve the URI syntax for OWS requests but I'm still not convinced of its value otherwise: I still worry that it makes little sense - and provides little real value - to try to converge the REST and OWS worlds. Regards, Jon On Nov 23, 2007 6:31 PM, Stefano Nativi <nativi@xxxxxxxxxxx> wrote:
Please, find attached the first draft of the discussion paper on Asynchronous Access issues. Any contribute is very welcome. --Stefano wcsplus mailing list wcsplus@xxxxxxxxxxxxxxxx For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
-- -------------------------------------------------------------- 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: