Hi Ed,
> > 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.
Yes, that's why I brought it up also. However, its only for a limited time
and we would try to limit access to the development branch of the HDF5 library
during that time. (As I said above, I'd still prefer to avoid going down this
path...)
Quincey
