netcdf-hdf mailing list is no longer active. The list archives are made available for historical reasons.
> At 07:07 PM 4/20/2005, you wrote: > > > This question came up today at the NASA briefing, when we were talking > > > about the netCDF 4 project. There was a weak but immediate and negative > > > reaction to using time as a proxy for creation order. The reason given > > was > > > that many applications would want to use the creation time as an > > attribute, > > > but that the times used would not necessarily give the same ordering as > > > creation time because different times might be relative to different time > > > zones. I have a feeling there were other cases, given the reaction > > people had. > > > > > > Of course this could only happen if people were allowed to change the > > > "creation time." And one could also argue that creation time is a > > > different attribute -- it's the time the link was created, not the time > > the > > > data was collected. But I have a feeling this would just lead to > > confusion. > > > > > > So at best, I think there is concern that this could led to confusion. I > > > tend to agree. > > > > Ok, I think we've heard enough customer push-back on this that we > > ought to > >provide both options and allow people to choose which they'd like. Here's a > >list of the fields that I'm planning on storing on storing for each link: > > - Name (indexable, must be unique, modifiable) > > - Creation time (indexable, may be non-unique, modifiable) > > - Creation order (indexable, unique, monotonicly increasing, > > non-modifiable) > > - Character set (i.e. ASCII, UTF-8, etc.) (non-indexable?, non-unique, > > modifiable) > > - Object address/link target (for hard/soft links) (non-indexable, may > > be > > non-unique (for multiple links to same object), modifiable?) > > > > Applications can determine which of the three indexable fields they'd > > like > >to have an index maintained for with a group creation property. They will > >choose an index for iteration, etc. with a group access property. > > > > Quincey > > It will be tough, if even possible, to do Creation order in parallel systems. > You would need to maintain this shared Creation Order Index (COI) quantity > across multiple processes dealing with racing conditions. Will there be > a COI per group (thus many COI's per file) > or a COI per file (thus multiple COI's per execution) > or one COI per execution? > > I think the second one, a COI per file, is the best (or least bad) choice. The first one (COI per group). I don't think it's a problem, since our metadata modification code requires collective calls by the application. Quincey