Tools to Build Clients

Toolkits based on C/C++ Libdap C++ library, the reference implementation of DAP2 Ocapi C library, client side only Libnc-dap Build clients using netCDF Loaddap Build clients using either Matlab or IDL

Two types of Clients Built using DAP implementations Complete access to all data sets served Well matched to network I/O operations Can be confusing to use - not intended for casual use Built using non-DAP APIs Easy APIs to use because many people are familiar with them - designed to be suited to application domains Not well matched to all data sets - data model mis-match between the API and the DAP2

Libdap C++ Basic use model: open a ‘connection’ to a server Get the data set’s metadata Access data Close connection

Libdap Connect Class Provides the interface for most client access The Connect constructor method is used to ‘connect’ to a URL Four methods are used to get the DAS, DDS, DDX and Data responses Other methods control miscellaneous features: Configure client-side caching Set username and password credentials Establish whether the client can process compressed responses Get the server/protocol version given a virtual connection has been established

Libdap example Look at libdap’s Connect.h source file for the complete interface to Connect The getdap client uses Connect Look at the libdap source file getdap.cc ‘name’ below is the URL minus any CE

Get a Response - How getdap gets the DDS The request. ‘expr’ is the constraint expression passed in using ‘-c’. The DDS object is a value-result parameter Getdap just prints the DDS using the DD::print() method

Getdap access data in much the same way… The data request. Note that the DDS is a value-result parameter here too. However the variables in this DDS are loaded with data The print_data function handles access to the data values

More about using libdap Responses from the ‘get’ methods of Connect are libdap container classes DAS: Semantic metadata; access values using methods bound to the DAS class DDS: Syntactic metadata; access name and type information for the dataset Data: Also returned using a DDS, but now the variables hold data

About Connect’s Get Methods DDS -vs- Data: The syntactic metadata is represented using a DDS object with variables that are instances of classes which specialize BaseType Or, think of the DDS/Variables objects as a parse tree typical of a compiler or interpreter This tree is used to record/express the variables’ types and their relationships

Where data resides In the DDS ‘parse tree’ data can be held in the variables. Accessor methods can be used to read values out. These Accessors behave like most data read functions (stdio’s read(), netCDF’s get_var(), et c.) providing data in blocks of memory.

Client APIs Summary C++ is hard(er) to use for many people, but the basic mode of operation for libdap (C++) and Ocapi ( C) is the same: Open Read Close The read operation used for our interfaces are very similar to those used with netCDF, HDF4, HDF5 Grab the metadata, look at the types, allocate memory, read data per variable. DAP APIs (libdap, Ocapi) provide a way to read several variables at once (optimized for network I/O), but the concepts are really the same.