netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
Hi Ed, Assuming you want to wrap the property lists, you may want to use their class/object-like properties. You can extend the HDF5 property list classes, or create new property list classes for netCDF-4 to use. See the test_genprop_class_addprop() code in test/tgenprop.c for how to extend an existing HDF5 property list class to add netCDF-4 specific properties. Some of the other code in that file may be useful for manipulating the property lists in HDF5 in other ways. Quincey > 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 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 > 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 >