Re: Schedule decision

• To: netcdf-hdf@xxxxxxxxxxxxxxxx
• Subject: Re: Schedule decision
• From: Quincey Koziol <koziol@xxxxxxxxxxxxx>
• Date: Fri, 22 Apr 2005 09:40:49 -0500 (CDT)

> 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

• References:
  • Re: Schedule decision
    • From: Albert Cheng