NOTE: The netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
Hi all,
I've been working on revising groups in HDF5 files (to allow for creating
groups which track creation order, among other things) and its become obvious
to me that my first attempt at implementing the indices required will not be
a good long-term solution. Switching horses midstream could delay getting the
HDF5 1.8.0 beta release by ~6 weeks if I change the indexing implementation
right now. I can, however, continue with the flawed index implementation I
currently have and build up to most of the API changes that would be required
and then go back and revise the guts of the library to use a better data
structure on disk for storing the indices required.
This would allow outside applications/libraries (like netCDF-4) to mostly
stabilize their code on the new API while I went back and reworked internal
things. This has several trade-offs that I can think of:
A - It gets a [reasonably] stable API to testers somewhat sooner.
B - Its going to take longer, because I'll have to re-do some work.
C - Files created during the "transition period" will _never_ be able to
be read by any other version of the HDF5 library - they must be
discarded by testers.
If we've got enough flexibility in our schedules, I would prefer to avoid
doing the re-work and just get things right first. But, since there is an
alternate plan that could work, I thought I would raise the issue.
What does everyone think?
Quincey
netcdf-hdf archives: