NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTE: The netcdf-hdf
mailing list is no longer active. The list archives are made available for historical reasons.
Quincey Koziol <koziol@xxxxxxxxxxxxx> writes: > 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 > > If the files produced by the temporary method of indexing are going to be unreadable in the future, that's not a good thing. Ed -- Ed Hartnett -- ed@xxxxxxxxxxxxxxxx
netcdf-hdf
archives: