Re: howdy all!

• To: Edward Hartnett <ed@xxxxxxxxxxxxxxxx>
• Subject: Re: howdy all!
• From: Russ Rew <russ@xxxxxxxxxxxxxxxx>
• Date: Wed, 09 Jul 2003 10:37:07 -0600

Ed,

> Russ, John, Robert, and I had a meeting here yesterday. From that
> meeting, and other sources, here is my understanding of the feature
> set of netCDF 4, in approximate order of priority.
> 
> * All features of netCDF 3.6
> * Use of HDF5 for file storage
> * Backward file-format compatibility
> * Backward API compatibility
> * Each var to have independent unlimited dimension
> * Anonymous dimensions
> * Bit packing
> * Chunking
> * Parallel I/O
> * (Unicode/ASCII) String data type
> * User-defined structs in data
> * Upgrades to ncgen/ncdump/NCL to reflect new features
> 
> Is there anything missing? Anything that should be removed? Anything
> that should be reprioritized?

This is a good summary, but I have a few suggestions.

"Large file support" is a feature, even if it doesn't require any
additional work on our part.  It's just a benefit inherited from using
HDF5 as the storage layer.

Some readers of this list may not know what netCDF 3.6 refers to.
That's the "final release" of netCDF 3 that has better
autoconf/automake/libtool support, bug fixes, and improved
documentation, but no new features or APIs.  It's just a cleaned up
3.5.1-beta11.

I would put "Parallel I/O" higher on the priority list, as that is the
main reason we're getting support from the modeling community for
this project.  Also, I would rephrase

> * Each var to have independent unlimited dimension

as just "Multiple unlimited dimensions", although it currently appears
that users needs would be satisfied by limiting each variable to at
most one unlimited dimension.  

I would also lower the priority of anonymous dimensions to below
String data type, since it wasn't mentioned in the proposal, and I
think the proposed enhancements should take priority over other
enhancements.

The "User-defined structs in data" could be divided into two
independent enhancements:

  * Support for structs
  * User-defined data types

with that priority.  The reason a user would define a data type might
be to define a name for a struct that would be used in other structs,
but I can imagine other uses as well ...

--Russ