Here're the meeting minutes from yesterday's HDF5DotNet virtual meeting on
Attendees: Jesse Lai, Scott Mitchell, Jason P., Gerd Heber
(My sincere apologies to Jason. I scribbled down his last name, but can't
find it anymore.)
The following topics were discussed:
HDF5DotNet in its current form is nothing but a minimal .NET wrapper
of the HDF5 library's C-API. No matter which .NET language you program in,
it will look more or less like C. In that regard HDF5DotNet can be compared
low-level API in h5py (http://h5py.alfven.org/). There may be a high-level
API in the future, but a clear separation between higher-level abstractions
and the low-level wrapper will be maintained.
Everybody is aware of the shortcomings (detailed below) in the current
The current version (including source, assemblies and documentation) will
be available at http://www.hdf5.net/ . This site will have official releases
snapshots. The consensus was to coordinate "breaking changes" in official
of HDF5DotNet with major new releases of HDF5, e.g., HDF 1.10.
Shortcomings in the following areas were identified:
The wrapper must be CLS (Common Language Specification) compliant.
Non CLS compliant interfaces (size_t, pointers, unsigned types etc.)
will be suppressed.
The naming is highly inconsistent and must be rectified. This is an example
of a "breaking change" and will be coordinated with a major release of HDF5.
The consensus was to follow the unmanaged C-API naming as closely as
for the low-level .NET layer (this is what h5py does). Any higher-level
abstractions will follow the .NET framework design guidelines.
Namespaces are underutilized in the current version. Some of the *Info types
enumerations are either in global (HDF5DotNet) scope or nested types.
This weakness will be addressed by introducing additional namespaces
(and fixing this will be a "breaking change").
The current practice of one exception type per method is considered
and will be revised. The goal is to arrive at one - and only one - usable
reporting/handling capability based on exceptions. It is unclear if any and
role H5E will play.
Many important functions/APIs are not wrapped in the current version of the
All participants (Jason, Jesse, Scott, Gerd) have gone out and added their
of favorites. They will contribute their enhancements to the "official"
The HDF Group will include and publish them in snapshots and official
This includes not only wrappers for individual calls, but also APIs like
H5PT, H5TB, H5IM, and H5DS. They will be available as HDF5DotNet snapshots
before being added to the release.
Testing needs to be drastically improved and participants will contribute
their own tests to a growing test suite. Using NUnit as the standard
is one of the proposals on the table.
I believe we have a sound understanding of the issues and solutions for
most of them. Combining all the contributions will mean a major leap
in API coverage, usability, and overall quality of the wrapper.
I would like to thank Jason, Jesse, Scott for their participation
and their contributions.
Please correct any omissions or misrepresentations on my part!
Gerd Heber | The HDF Group
Email: firstname.lastname@example.org | 1800 South Oak Street
Work: (217) 531-6109 | Suite 203
Mobile: (217) 419-0660 | Champaign, IL 61820