Ed Hartnett wrote:
IMHO, i think we need to wrap all hdf5 calls; they may provide some
functionality we dont want to provide, now or in the future. so we
should look at all properties and consider if we want to include it or not.
Quincey raises an interesting question: are we going to somehow wrap
HDF5 property lists? Or shall we expose them to the netCDF-4 user?
For example, the HDF5 file creation process involves two property
lists, one for creation properties and one for access properties.
Now we currently make various assumptions about what is desired when
handling a nc_create call. That is, we just go with default property
But we probably also want to add a function to netcdf which directly
exposes those property lists, allowing the user to construct and
manipulate them with HDF5 functions, and then taking the property
lists and handing them down to the HDF5 file creation function that
This is a bit of a weird mix of HDF5 and netCDF-4, but it will allow
the user to take advantage of new features in HDF5 without updating
any netCDF-4 code.
Or perhaps this is a bridge too far for Russ and Mike in terms of
mixing the interface.
I note that we face a similar decision about compound types. We could
wrap HDF5 functions in netCDF functions that conform with our current
interface, but why not just use the perfectly good HDF5 interface for
creating compound types, and then taking the hid_t into an netCDF
(Of course then we have to ask: what if they use a HDF5 type not
supported in netCDF, if there are any such types?)
theres 2 motivations for this: 1) netcdf-4 should be a simpler data
model; if a user wants full hdf-5, they already have that. 2) we want to
support a 100% java interface to netcdf-4. this may limit some of the
things we can do, for example there is currently no java implementation