NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
> 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
thredds archives: