Here're the meeting minutes from yesterday's HDF5DotNet virtual meeting on EVO.
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 to the 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 version. The current version (including source, assemblies and documentation) will soon be available at http://www.hdf5.net/ . This site will have official releases and snapshots. The consensus was to coordinate "breaking changes" in official releases of HDF5DotNet with major new releases of HDF5, e.g., HDF 1.10. Shortcomings in the following areas were identified: CLS Compliance: --------------- The wrapper must be CLS (Common Language Specification) compliant. Non CLS compliant interfaces (size_t, pointers, unsigned types etc.) will be suppressed. Naming: ------- 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 possible for the low-level .NET layer (this is what h5py does). Any higher-level abstractions will follow the .NET framework design guidelines. Scope: ------ Namespaces are underutilized in the current version. Some of the *Info types and 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"). Error Handling: --------------- The current practice of one exception type per method is considered inappropriate and will be revised. The goal is to arrive at one - and only one - usable error reporting/handling capability based on exceptions. It is unclear if any and what role H5E will play. API Coverage: ------------- Many important functions/APIs are not wrapped in the current version of the wrapper. All participants (Jason, Jesse, Scott, Gerd) have gone out and added their own list of favorites. They will contribute their enhancements to the "official" source and The HDF Group will include and publish them in snapshots and official releases. This includes not only wrappers for individual calls, but also APIs like H5PT, H5TB, H5IM, and H5DS. They will be available as HDF5DotNet snapshots first before being added to the release. Testing: -------- Testing needs to be drastically improved and participants will contribute their own tests to a growing test suite. Using NUnit as the standard environment is one of the proposals on the table. Summary: -------- 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! Best regards, Gerd Heber Gerd Heber | The HDF Group Email: [email protected] | 1800 South Oak Street Work: (217) 531-6109 | Suite 203 Mobile: (217) 419-0660 | Champaign, IL 61820 _______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
