There has been a lot of change to the netCDF C/Fortran/C++ library architecture and build system since the 4.0 release, and there is more to come.
The first thing that changed was the addition of netCDF-4, and the switch to automake/libtool.
After that, Dennis added the remote access client, which caused us to change the architecture again. Now we have a dispatch layer. The dispatch layer decides, when you call a function like nc_open, whether you want to open a netCDF-4/HDF5 file (in which case nc4_open will be called), a classic or 64-bit offset file, in which case nc3_open will be called, or a remote client access using the DAP2 protocol, in which case NCD3_open will be called.
This allows all the code for a dispatch interface to be in one directory. The netCDF classic code is all in libsrc, the netCDF-4 extensions are in libsrc4, the DAP2 remote access client is in libdap2, etc. In practice, this allows me to maintain the netCDF-4 code, Russ to maintain the classic code, and Dennis to maintain the remote access client code, while all working in different directories.
We are so happy with the way this dispatch architecture works that we are planning on extending it in a number of ways.
- The HDF4 SD access, and the parallel-netcdf access, which are now handled as special cases of netCDF-4/HDF5 files, will be promoted to full dispatch level, adding two new directories.
- Dennis is working on other remote access protocols, including some new remote access protocols. Each will add a new directory.
- Significant refactoring of the dispatch layer is underway, which may change the architecture further.
- We intend to open up the dispatch layer so that users can extend netCDF to handle their own, perhaps completely local, formats. This will probably require further changes to the architecture and build system.
In addition to all of the above, we also intend to split the fortran and the C++ libraries into their own distributions. This will allow users to update them only when they change. There have been no changes in the fortran APIs for some years, yet users still rebuild them every time a new library release comes out. This is not necessary with shared libraries. The fortran libraries can be built and will point at the most recent C library. If the C library is updated, the Fortran library, without being rebuilt, will use the new C library.
The conclusion is that we are only part-way through a time of change in the packaging and architecture of the netCDF C/Fortran/C++ libraries.
