> On WPS I'm not really in disagreement -- WPS suffers from the usual OGC
> premature standardisation. However in our experience the lightweight
> "processing as HTTP GET" approach quickly runs into scalability problems:
>
> I too agree with Roy on this. As someone who has been on both ends of the
client and the server dealing with some of the OGC standards can be
difficult. Typically, being on the server side is easier because you can
essentially just use the components of the standard that suit your needs.
In essence, you have your own profile. Its much much more difficult being
on the client side of a standard. There you have to be able to deal with
all the components of the standard that servers might throw at you.
> 1. Many functions on our data aren't going to complete within the timeout
> of an HTTP GET so some sort of asynchronous pattern is needed
>
While we didn't follow the WPS standard we had to address this in the NLAS
LiDAR work at Unavco:
https://nlas.unavco.org/repository
Here, the service requests can either be synchronous or asynchronous:
https://nlas.unavco.org/repository/nlasdocs/api.html
If asynchronous we came up with a simple xml job status format that works
pretty well. The key here is "simple". When in OGC land too often that term
is forgotten.
> 2. The results may be big. It makes much more sense to create the output
> resources (in the Restful sense) then let the user download them, or even
> interrogate them with OPeNDAP (now possible with COWS-WPS).
> 3. An HTTP URL can only hold so much information. Google Charts have
> moved from a HTTP GET based system to an AJAX API, I'm guessing partly for
> this reason.
>
The GET url length limits can be problematic and varies with web servers
but will get you in the end. We had to jump through quite a few hoops to
support REST-ful image generation requests for the IDV display service in
RAMADDA, e.g.:
http://ramadda.org/repository/entry/show/Home/RAMADDA+Examples/Geo-Data/Gridded+Data/gfs80.nc?entryid=b835f612-5975-468f-86af-16e1a8e25219&output=idv.grid
While storing server side state is one option here it defeats the
self-contained, REST-ful paradigm.
-Jeff
