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: