RFC-HDFG-2026-001: String-Based Filter Configuration API — Request for Community Feedback

HDF5 Library
1

Hi all,

We are seeking community feedback on a new RFC proposing a unified, string-based filter configuration interface for HDF5.

The current H5Pset_filter interface requires filter parameters to be passed as raw unsigned int arrays (cd_values). This works well for integer parameters but is cumbersome for filters that accept floating-point values (rates, tolerances), and produces opaque sequences that are difficult to use from the command line or high-level language bindings.

This RFC proposes a new function, H5Pappend_filter, that accepts filter parameters either as a raw cd_values array or as a human-readable key=value string (e.g., “mode=rate, rate=3.5”). The design:

  • Adds H5Pappend_filter and the H5Z_params_t tagged union to the public API
  • Introduces H5Z_class3_t with optional string-configuration callbacks for plugin authors
  • Preserves full backward compatibility — existing APIs, plugins, and call sites are unchanged
  • Covers Fortran and Java bindings, h5repack/h5dump integration, and a normative cd_values packing convention for floating-point parameters

We are particularly interested in feedback on:

RFC_HDFG_2026_001-1.pdf (334.9 KB)

  1. The H5Z_params_t tagged union and the H5Pappend_filter function signature, including feedback on the key-value parser.
  2. The H5Z_class3_t plugin callback contract, especially the two-pass set_config protocol
  3. The normative cd_values packing convention for double/float parameters
  4. The Fortran and Java binding designs
  5. Any use cases or edge cases not addressed by the current design

Please reply to this thread or preferably on the related issue at your earliest convenience:

Thank you,
Scot Breitenfeld

Working Group Meeting 5/7/26
Learn about the String-Based Filter Configuration API RFC - Scot Breitenfeld Call the Doctor 5/12/26
2

I haven’t read the entire RFC yet, but I’m also working on extending the H5Z_class_t struct for the Accelerator-native I/O pipeline work that I’m preparing to upstream. Let’s coordinate so that both of our updates to the H5Z_class_t get into the same release and we don’t end up with H5Z_class4_t in the release immediately after H5Z_class3_t is introduced.