Talk:Server-side Functions

Tentative specification

This is a first tentative specification, just to see how far we can go with the ideas alreay in mind. Feel free to change, edit, adapt, modify or leave comments. --RobDeAlmeida

Capabilities introspection

The capabilities response is requested by accessing the URL /functions.xml. Perhaps it would be also a good idea to embed the response in the thredds catalog, or perhaps put at least a pointer to it?

Capabilities response

This is a plain old xml response, inspired by XINS. Parameters are positional, and always required:

<functions xmlns="http://xml.opendap.org/ns/SSF">
  <function name="mean">
    <description>Calculates mean over axis between two points.</description>
    <example>mean(sst,"lat",10,40)</example>
    <input type="Grid">
      <description>The name of the variable to be averaged.</description>
    </input>
    <input type="String">
      <description>The name of the axis.</description>
    </input>
    <input type="Float64">
      <description>The initial value of the averaging.</description>
    </input>
    <input type="Float64">
      <description>The last value of the averaging.</description>
    </input>
    <output type="Grid">
      <description>A new Grid with a degenerated axis.</description>
    </output>
  </function>
</functions>

Problem: how do we specify more than one type of input type allowed? I can think of:

<input type="Grid Array">

But the list could get big quickly if we want to list Int32, UInt16, etc. It would be nice to have a shortcut to the base types:

<input type="Array Base">

With Base meaning all the base types.

Syntax specification

RobDeAlmeida proposed two approaches: first, for simple requests use the standard DAP syntax for calling funtions; second, for complex requests, allow a user submitted script to be associated with a newly created function. This second suggestion is a bit controversial because it requires some client software (Ferret, eg) to be rewritten, or at least relinked with a HTTP library that allows POSTs. It also breaks a request in two separate steps. Following Roland Schweitzer's suggestion, the syntax should be tests with the Server Side Functions Use Cases proposed by Steve Hankin.