Re: how often does HDF binary format change?

Hi Ed,

> Greetings to HDF HQ from NetCDFville.
    I see we're both early risers this morning... :-)

> I wonder how often you guys have to change the underlying binary
> format of the data in support of new releases of HDF5?
    We've tweaked the file format a little bit with each major release so far
(and sometimes with minor releases also).  This shouldn't be a problem for
applications which call the library though, since we provide full backward
compatability. (and as much forward compatibility as possible)

> And is there some format version number in the data file? I presume
> there is.
    We've learned that a single version number is not very useful, so we've
learned to include version #'s on all the structures inside the file (we missed
a couple, but I'm trying to correct that :-).  This "micro-versioning" has been
very useful and should allow us to avoid major revisions of the "entire" format
for the foreseeable future.

        Quincey
>From owner-netcdf-hdf@xxxxxxxxxxxxxxxx 25 2003 Oct -0600 07:01:55 
Message-ID: <wrxekx1xygs.fsf@xxxxxxxxxxxxxxxxxxxxxxx>
Date: 25 Oct 2003 07:01:55 -0600
From: Ed Hartnett <ed@xxxxxxxxxxxxxxxx>
To: netcdf-hdf@xxxxxxxxxxxxxxxx
Subject: important implementation note for range checking and type conversion...
Received: (from majordo@localhost)
        by unidata.ucar.edu (UCAR/Unidata) id h9PD1u0q015504
        for netcdf-hdf-out; Sat, 25 Oct 2003 07:01:56 -0600 (MDT)
Received: from rodney.unidata.ucar.edu (rodney.unidata.ucar.edu 
[128.117.140.88])
        by unidata.ucar.edu (UCAR/Unidata) with ESMTP id h9PD1tOb015474
        for <netcdf-hdf@xxxxxxxxxxxxxxxx>; Sat, 25 Oct 2003 07:01:55 -0600 (MDT)
Organization: UCAR/Unidata
Keywords: 200310251301.h9PD1tOb015474
Lines: 20
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-netcdf-hdf@xxxxxxxxxxxxxxxx
Precedence: bulk

Quincey,

Russ points out that my code allocates giant chunks of memory to
convert data types. I only did this because I figure you'll supplant
all this code shortly anyway.

Presumably your code will have a reasonable memory allocation strategy,
such that you're not grabbing giant chunks of RAM, nor doing separate
small allocations millions of times. Right?

The final work on signed vs. unsigned NC_BYTE is that, except for
range checking, we never care, and the information (i.e. whether
NC_BYTE data are signed or unsigned) is not stored in the file. The
user just has to know that for themselves.

For the purposes of range checking, we treat all NC_BYTE data as
signed. This will result in errors when the user is actually intending
this to be unsigned data, but we can live with that.

Ed

>From owner-netcdf-hdf@xxxxxxxxxxxxxxxx 25 2003 Oct -0600 07:05:13 
Message-ID: <wrxad7pxyba.fsf@xxxxxxxxxxxxxxxxxxxxxxx>
Date: 25 Oct 2003 07:05:13 -0600
From: Ed Hartnett <ed@xxxxxxxxxxxxxxxx>
To: netcdf-hdf@xxxxxxxxxxxxxxxx
Subject: how about adding cygwin to the list of supported HDF platforms?
Received: (from majordo@localhost)
        by unidata.ucar.edu (UCAR/Unidata) id h9PD5E2I018995
        for netcdf-hdf-out; Sat, 25 Oct 2003 07:05:14 -0600 (MDT)
Received: from rodney.unidata.ucar.edu (rodney.unidata.ucar.edu 
[128.117.140.88])
        by unidata.ucar.edu (UCAR/Unidata) with ESMTP id h9PD5DOb018893
        for <netcdf-hdf@xxxxxxxxxxxxxxxx>; Sat, 25 Oct 2003 07:05:13 -0600 (MDT)
Organization: UCAR/Unidata
Keywords: 200310251305.h9PD5DOb018893
Lines: 12
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-netcdf-hdf@xxxxxxxxxxxxxxxx
Precedence: bulk

Howdy HDF HQ!

How about adding Cygwin to the supported platforms? In terms of
porting it is almost identical to linux, and lots of people use it,
and, most importantly, I use it...

I'm about to grab the 1.6.1 source and try it, so I'll let you know
how it comes out.

Thanks,

Ed