netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
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 lists. 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 gets called. 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 updatingany 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 function? (Of course then we have to ask: what if they use a HDF5 type not supported in netCDF, if there are any such types?) Ed
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 of szip.