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.

Re: [thredds] nco as a web service

> I am old and slow, but suppose I am in OpeNDAP, are you proposing
> to separate say constraint expressions and server-side function
> requests basically the same (ie I just scan what is after each
> comma) or do you propose some method that signifies in the URL
> that what follows is an expression?  In F-TDS and GDS the form of
> the URL is:

First, I am proposing to subsume DAP constraints.
Second, I am proposing, like DAP, to put the expressions
in the query part of the URL (i.e. after the '?').

>
> 
http://machine:port/thredds/dodsC/dataset_expr_{dataset2,dataset3,...}{expression1;expression2;...}.URLsuffix?constraint

So, I would rewrite this as something more-or-less like this:
http://machine.../dataset?expression1,expression2,...
Where the expressions would include the references to dataset2, dataset3,
and the constraint.

> BTW, the reason I have asked about the experience of people who
> are using F-TDS and GDS on whether synchronous requests can cover
> the large majority of cases, is because I am very partial to
> systems where the URL completely defines the request, and hence
> essentially use GET as the verb.
The synchronous/asynchronous issue is, for me, a separable issue.
I should note that GET has a limit on the size of URLS, so
there needs to be ways to deal with that. Two possibilities are
1) use POST or PUT, or 2) provide a way to upload a long expression
in parts USING multiple GETs.

> The reason for this is long
> experience.  where client code has broken with changes in
> operating system and/or application, fixes were slow in coming,
> so many users were left with nothing working.  In a system where
> the URL completely defined the request, say ERDDAP, in Matlab:
>
> > > link='http://coastwatch.pfeg.noaa.gov/erddap/griddap/erdBAsstamday.mat?sst[(2010-01-16T12:00:00Z):1:(2010-01-16T12:00:00Z)][(0.0):1:(0.0)][(30):1:(50.0)][(220):1:(240.0)]'; 
> > > F=urlwrite(link,'cwatch.mat');
> > >
>
> Will get the related file, and the entire command is in Matlab,
> no extra code required.  The same in R is:
>
> > > download.file(url="http://coastwatch.pfeg.noaa.gov/erddap/griddap/erdBAsstamday.nc?sst[(2010-01-16T12:00:00Z):1:(2010-01-16T12:00:00Z)][(0.0):1:(0.0)][(30):1:(50.0)][(220):1:(240.0)]", destfile="AGssta.nc",mode='wb') 
> > >
>
> again, "download.file" is an R command.
I think that we do not want to be R/MATLAB specific
in a proposal to put stuff in URLs. I would rather
propose to allow uploading of R/MATLAB scripts to serve
as additional, user-defined functions.

I would prefer to
> maintain this simplicity and cover 80% of the cases if possible,
> than cover the rest but where more complex, application specific
> code would have to be developed and maintained.

Agreed. However my assumption is the the output of any function that
is not assigned to a single-assignment variable will be returned as part
of the response; but other ways of specifying this are possible within
the functional framework I am proposing.

=Dennis Heimbigner
 Unidata
  • 2012 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the thredds archives: