Programatize filter name <--> id map

THG has defined a process for registering a new filter and maintains those registered filters here, https://support.hdfgroup.org/services/filters.html.

I wonder if it makes sense and would be possible to programatize that page and include, minimally, the filter name strings and registered ids in releases such that it can be queried at run-time via some new HDF5 library API calls (e.g. H5Zget_filter_id_by_name(char const *partial_name) using a strcasestr() match)). It should be possible to code-generate this data from the filters.html web page (or maybe a json equivalent of that page) and include it in releases.

Hello!

03.10.2018 0:34, miller86 пишет:

THG has defined a process for registering a new filter and maintains
those registered filters here,
https://support.hdfgroup.org/services/filters.html.

I wonder if it makes sense and would be possible to programatize that
page and include, minimally, the filter name strings and registered ids
in releases such that it can be queried at run-time via some new HDF5
library API calls (e.g. H5Zget_filter_id_by_name(char const
*partial_name) using a strstr() match)). It should be possible to
code-generate this data from the filters.html web page (or maybe a json
equivalent of that page) and include it in releases.

This is a nice idea. Do you think a number of #define constants
H5Z_FILTER_LZO=305, H5Z_FILTER_BZIP2=307, … would be equally good?
The latter could be elegantly achieved via e.g.
https://www.crummy.com/software/BeautifulSoup :wink:

Best wishes,
Andrey Paramonov

I think using define constants would be ok, as long as there was an easy way for newbie users to discover them maybe either because they are part of the documentation maybe here, or there was a command-line tool to query a given HDF5 install, h5avail (maybe), for the all/available filters (although dynamically loaded plugins would require that the associated paths be in HDF5_PLUGIN_PATH for such a tool to see them).

The reason I proposed string<–>id map is that it supports near matches whereas #define constants require exact prior knowledge.

Hi Mark and Andrey,

I agree, it is an interesting idea. I’ve entered an enhancement report HDFFV-10600.

Thank you!

Elena