Re: Schedule decision

• To: netcdf-hdf@xxxxxxxxxxxxxxxx
• Subject: Re: Schedule decision
• From: Quincey Koziol <koziol@xxxxxxxxxxxxx>
• Date: Wed, 20 Apr 2005 19:07:32 -0500 (CDT)

Hi Mike,

> 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

> 
> Mike
> 
> At 10:16 AM 4/19/2005, Quincey Koziol wrote:
> > > Quincey Koziol <koziol@xxxxxxxxxxxxx> writes:
> > >
> > > >     I was planning on including a hidden field to disambiguate 
> > objects that
> > > > were created at the same time, so this wouldn't happen.  Since there's 
> > > > no
> > > > advantage to using a creation order field instead of using the 
> > creation time
> > > > when determining the n'th object inserted into a group (when 
> > factoring deleted
> > > > objects into the equation), I'm still leaning toward using a time 
> > instead of an
> > > > index for this purpose.  Using the time provides the same 
> > functionality and
> > > > adds information as well.
> > > >
> > > >     I'm still somewhat split on the issue however and would welcome 
> > persuasive
> > > > arguments in favor of one mechanism or the other.  :-)  I'm also 
> > thinking about
> > > > including both fields (creation order and creation time) and allowing 
> > users to
> > > > create an index on either, to suit their particular needs...
> > >
> > > Quincey,
> > >
> > > What happens is a machine with an inaccurate time adds a variable to a
> > > dataset?
> >
> >     It'll get the "wrong" creation time and inserted in the index
> >appropriately, as you'd expect.  I don't think this is a major problem 
> >though,
> >because I don't think that most files will get edited on multiple machines in
> >a very short timeframe.
> >
> >     Quincey
> 
> --
> Mike Folk, Scientific Data Tech (HDF)   http://hdf.ncsa.uiuc.edu
> NCSA/U of Illinois at Urbana-Champaign          217-244-0647 voice
> 605 E. Springfield Ave., Champaign IL 61820     217-244-1987 fax 
> 

• Follow-Ups:
  • Re: Schedule decision
    • From: Albert Cheng
  • Re: Schedule decision
    • From: Ed Hartnett

• References:
  • Re: Schedule decision
    • From: Mike Folk