OC Library Features and Analysis: Difference between revisions

From OPeNDAP Documentation
⧼opendap2-jumptonavigation⧽
Line 10: Line 10:


Using a supplied xdr.c but a system xdr.h - this will be a problem somewhere (e.g., FC 8). Lets use system one or all our own headers.
Using a supplied xdr.c but a system xdr.h - this will be a problem somewhere (e.g., FC 8). Lets use system one or all our own headers.
Or use Ocapi's XDR - we don't need XDR for Unix, but we do for win32.


== Features ==
== Features ==

Revision as of 21:08, 26 January 2009

Questions

How do you build the Getdata* structure? That is, wehn you call makegetdata(), how do you build the OCnode* target structure?

How do the startp, countp, stridep parameters fit into the overall pattern of DAP's constraint expressions? For example, lots of DAP things are not arrays.

Why does the oc code parse teh constraint expression since the server is the place where it's actually evaluated?

Once you get a Getdata* structure, how do you get the data out?

Using a supplied xdr.c but a system xdr.h - this will be a problem somewhere (e.g., FC 8). Lets use system one or all our own headers.

Or use Ocapi's XDR - we don't need XDR for Unix, but we do for win32.

Features

Features likely needed by any general C-language client-side API for DAP

features already implemented in oc

  1. get variables (primitive types)
  2. get array varaibles (of primitive types)
  3. get attributes

features that can be implemented with little effort

little means using the current library's structure and some more code

  1. make print representations for all responses (DAS, DDS, DataDDS)
  2. http authentication support
  3. SSL suport
  4. cookie support
  5. .dodsrc support (read and write)
  6. compression support
  7. testing - write automated tests
  8. nightly builds
  9. automated build (autoconf, make, libtool)
  10. more typical API (open, read, close all based on an opaque parameter - object - and C's existing data types)

features that will be hard to implement

hard means extending the existing library's structure/implementation

  1. get structures (flat and nested)
  2. get sequences (flat and nested)
  3. get grids
  4. get arrays of constructor types
  5. parse XML(DDX, DataDDX*)
  6. shared dimensions*
  7. groups*
  8. allow constraints for the DDS
  9. allow constraints for the DataDDS (e.g., lat or lon or lat and lon togther)
  10. DAP 3.x protocol version negotiation

Use Cases

Definitions

Background

Deliverables

Period of use