DODS Software - Version 3.4

DODS (C++) 3.4

OPeNDAP C++ 3.4 Release is now available (12 January 2004). See below for major enhancements and fixed.

Download the OPeNDAP C++ 3.4 source code from our DODS 3.4 ftp site. Binary distributionsa are also available for the supported platforms The following links will help guide you through selecting a platform and the distribution files you will need.

Changes between 3.2 and 3.4

Code changes

• Using libcurl instead of libwww.
• URL dereferencing done with curl instead of Perl.
• C++ DAP is now thread-safe.
• New interface for DAS and DDS classes.
• Core compiles with gcc 3.2.1, Visual C++ 6.0 and gcc 2.95.
• Bug fixes
• Server and client code can once again deal with compressed responses.
• Rolled new netCDF fix into nc-dods. This fixes an issue with performance seen with data on NFS mounted disks.

Client usage changes

• Passwords can be included in URLs.
• Digest authentication is now supported.

Server usage changes

• dods.rc
• A smart time-out capability has been added to the servers.
• statistics

New software

• OPeNDAP AIS prototype is available
• netCDF client and server upgraded
• DODSter module added to emulate the MODster software.

Server usage notes

• Compression and caching decompressed files.
• Register your data set(s).
• Prettifying the DODS Directory response.

Known problems:

• The JGOFS server requires a patch to build on the Dec Alpha using gcc/++ 3.3.
• The DODSter feature does not work with with Apache 2.x web server. See details

CODE CHANGES

• The DODS core now links to libcurl instead of libwww for WWW functions. The libcurl library is smaller than libwww, is being actively developed, and is MT-safe.
• The server dispatch scripts no longer use the Perl HTTP, MIME and LWP classes. Instead, URL dereferencing is done with curl, a freestanding binary that is part of the libcurl build.
• The core software is now multi-thread safe.

• The interface to several important classes has been augmented. The DAS and DDS classes have a new set of interfaces so that STL iterators can be used to manipulate their contents. The Old Pix interfaces are still present, although uses of Pix that rely on those objects being void pointers may fail in certain circumstances.

  To write out the names of all the variables in a DDS, you would use Pix code like this:

                     for (Pix p = dds.first_var(); p; dds.next_var(p)) {
                         cout << dds.var(p)->name() << endl;
                     }
                  

  Using the STL for the same purpose, you would do this:

                     for (DDS::Vars_iter i = dds.begin_var(); 1 != dds.end_var(); ++i) {
                         cout << (*i)->name() << endl;
                     }
                  

  There have also been some additions to the DAS, DDS and AttrTable that make it easier for non-C++ programs to traverse those containers.

  For example, in the DDS class, we have the new method:

                     Vars_iter get_vars_iter(int i);
                  

  In AttrTable we have:

                     Attr_iter get_attr_iter(int i);
                  

  Both of these make it possible to access members of the DDS and DAS containers from C code using a simple integer index. This is important because C programs cannot create the fancy STL iterator objects. (They can fake a Pix pointer, but this leads to problems and should not be done.)

• The C++ DAP now builds with gcc 3.2.1, in addition to gcc 2.95 and Visual C++ 6.0. These are the compiler versions that have been tested. Other versions may also work. Other compilers may also work as long as they support the STL (Standard Template Library).

• Server bug fixes have included fixes to Sequence constraint behavior, the Grid constraint expression function, and memory leaks.

  The grid() server-side function is now part of all servers. Suppose you have a Grid variable SST that looks like:

                     Grid {
                       Array:
                         Byte SST[lat=1024][lon=1024];
                       Maps:
                         Float64 lat[1024];
              	       Float64 lon[1024];
                     } SST;
                  

  You can use the following constraints:

                     ?grid(SST,"lat>10.0","lat<20.0")
                  

  Returns the part where "lat" is between 10.0 and 20.0. All the "lon" values are returned.

                     ?grid(SST,"10.0<lat<20.0")
                  

  This does the same thing, with a simpler syntax.

                     ?grid(SST,"10.0<lat<20.0","-80.0<lon<-30.0")
                  

  This returns the part of the Grid falling in the specified latitude/longitude box.

  The grid() function operates under the following restrictions: The map vectors must be monotonic for the selected Grid. The quoted expressions must contain only the names of map vectors of the Grid, constants and relational operators.

  The function does not take into account the special characteristics of latitude and longitude. If map vectors wrap in an odd way, the behavior of grid() may not be what you expect.

  Note: This is not a geoselection function. Map vectors may be composed of any of the simple DAP types. (Like strings, for example.)

• Server and client code can once again deal with compressed responses. The libcurl library did not initially handle compressed responses. After some OPeNDAP contributed enhancements were added to libcurl it now supports compressed responses.
• Rolled a new netCDF fix into the nc-dods code. This fixes an issue with performance seen when reading data on NFS mounted disks. The fix involved removing unneeded nc_sync() calls.

CLIENT USAGE CHANGES

• The DODS core now supports the (nonstandard) password-in-URL syntax. If you are accessing a password-protected data set, you can include your user name and password directly in the URL like so:

                    http://user:password@dods.org/cgi-bin/nph-nc/data.nc
                  

  Including a password in the URL allows the user to avoid the extra overhead of the authentication dialog box that was the only option in earlier releases.

• Digest authentication is now supported.

SERVER USAGE CHANGES

• The name of the server configuration file has been changed from dods.ini to dods.rc. The dods.rc server config file is a real server config file; i.e., there's no longer any need to edit the Perl scripts.
• A smart time-out capability has been added to the servers. It is configurable using the dods.rc file (the default is to never time out). This addresses a bug where a server fails to exit when a client has been killed.

• A new feature of the servers allows the DODS project to gather access statistics from sites who choose to allow it. During the installation process (via the installServer script), the server administrator is asked for permission to gather this data. If permission is granted, the server will return DODS access data (no other data is provided) to queries that emanate from one of the official DODS web sites. The statistics feature refers only to DODS server accesses, not to any accesses of other web content.

  Note: The DODS project understands that allowing access to the DODS/DAP server's usage information might not be acceptable to some server administrators. However, allowing us access to the server's usage information will help us direct future software development efforts. If you choose to enable this feature, only the local host and official DODS/OPeNDAP machines will be able to gain access to the statistical information.

  The file $DODS_ROOT/etc/INSTALL-servers contains more information about what data is gathered and how to configure or disable this feature.

NEW SOFTWARE

• A very early prototype Ancillary Information Server (AIS) is available. This version is for concept testing, and is likely to contain bugs and need substantial improvement. However, the DODS project also needs people to contribute feedback to its development, so it is being made available for that purpose. Contact the project if you're interested in testing this software.
• The DODS-enabled netCDF client library and servers have been upgraded to be compatible with netCDF 3.5. The netCDF client library now use a DODS error object to send the netCDF 3.5 system error codes to the client. The client library reports errors received from the servers in addition to DODS internal and local error codes. Also invalid_error messages due to handling error exception are fixed.

• DODSter capabilities have been added to the server software. DODSter is an experimental system created in a partnership with the Earth System Science Workbench that provides a way for DODS servers to use the MODSter system to access MODIS data. With DODSter you can use a DODS server to fetch a URL from MODSter.

NOTE: There's a known problem with DODSter and the Apache 2.x web servers. Until we fix this problem, it will only work on the older 1.x servers. The problem is that Apache breaks our simple URL enveloping scheme. This will be fixed in an upcoming release of the DODS/OPeNDAP server software.

For more information, see: http://essw.bren.ucsb.edu/modster/ or contact jgallagher@gso.uri.edu.

To access MODIS data from MODSter using a DODS/OPeNDAP server, pass the server a MODSter URL enveloped in a DODS URL. It sounds complicated, but it's really pretty simple.

Here's a short review of the structure of a DODS/OPeNDAP URL. A regular DODS/OPeNDAP URL looks something like:

http:///dods-3.4/nph-dods/data/myfile.hdf.