Re: [wcsplus] more on asynchronous response

NOTE: The wcsplus mailing list is no longer active. The list archives are made available for historical reasons.

Hi Ethan and all,

Comment below:

On Wednesday 24 October 2007 01:11, Ethan Davis wrote:

That sounds good. Though I think of the status monitor as an extension
of the body of the 202 response (which is the XML document mentioned
above that we need to define). Perhaps this is part of why I had not
thought of using redirects. I see this status monitor XML document as
removing the asynchronous response from the realm of the HTTP
specification (sort of) and instead moving it into the xlink:href world.
So, rather than the status monitor response code redirecting us to the
new resource, the body of the status monitor response would indicate the
new resource was available and provide a link to the new resource. So,
here's my take:

a) client GETs the Ures URI
b) if delayed, response 202 code with
b1) Location header providing status monitor URI (Ustatus)
b2) Body containing XML document with status, estimate of completion,
and link to status monitor URI (Ustatus)
c) client GETs the Ustatus URI:
c1) if still not available, response code 200 with XML document same as
response b2 (maybe without Ustatus link).
c2) if available, response code 200 with XML document (similar to
response b2?) that indicates the resource is ready and provides a link
to  the resulting resource.

Some very simple XML possibilities ...
For b)
<asynchResponse status="processing" completionEstimate="2007-10-24T02:34">
  <statusMonitor xlink:href="some URI" />
</asynchResponse>

For c1)
<asynchResponse status="processing" completionEstimate="2007-10-24T02:34"
/>

For c2)
<asynchResponse status="done">
  <generatedResource xlink:href="some URI" />
</asynchResponse>
This status monitor is conceptually very similar to the 'ExecuteResponse' document in the Web Processing Service Specification. So as a starting step (and to get us going) we could take this direct from the WPS spec for WCS 1.0+ and then depending on how we find it, enhance it from there and also feed our findings back to the WPS working group. I would prefer to see us work with an existing specification rather than try and define our own schema from scratch. My concern being that we might otherwise spend all our time designing new specifications and not implementing them... :-) 

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