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
>
