Re: [wcsplus] Discussion paper

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.


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.


wcsplus mailing list
For list information or to unsubscribe, visit:

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

  • 2007 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the wcsplus archives: