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
