Mark Kittisopikul

Please take a look at the JavaCPP project: https://github.com/bytedeco/javacpp-presets/blob/master/hdf5%2FREADME.md https://central.sonatype.com/artifact/org.bytedeco/hdf5-platform They have been publishing native HDF5 libraries on maven for years, although we could use help updating this for recent...

Regarding thr SciJava project, @ctrueden and I have discussed this in the past. This would be an alternative mechanism, but we lack the infrastructure to keep up with HDF development....

snappy is not currently included in https://github.com/Blosc/c-blosc/tree/main/internal-complibs which is where numcodecs would normally obtain the compression libs from.

conda-forge has been building blosc (v1) with snappy: https://github.com/conda-forge/blosc-feedstock/blob/c57a4e59b3cf26bb7c87a9950ff57e0c4ed1b7b3/recipe/meta.yaml#L25

I agree that there should be a `latest`, `dev`, or `develop` branch that new pull requests should go into. Only after pull requests are merged into this branch should appropriate...

I lean heavily towards snake_case at this point. Zarr v3 uses snake_case in many cases and that is not going to change. * `zarr_format` * `node_type` * `data_type` * `chunk_grid`...

An alternative to the string lookup for the compressor, would be to just pass in `CodecZstd.ZstdCompressor` directly, specifically an instance created by `CodecZstd.ZstdFrameCompressor()`. Via a conversion mechanism, we could wrap...

As for how to proceed here, I do think @nhz2 has some legitimate concerns. The way I would fix the threading issues is by making a copy of the compressor...

@nhz2 Can you replace this with a ChunkCodecLibZstd.jl implementation? @bjarthur needs this as soon as possible. Otherwise, I will need to refactor this.

Closed in favor of #180