Lachlan Deakin
Lachlan Deakin
I think it is a good idea to simplify the API with something like `filters`/`compressor`, but compressor should not strictly map to `BytesBytesCodec`. Possible future compressors like [zfp](https://docs.rs/zarrs/latest/zarrs/array/codec/array_to_bytes/zfp/index.html) and [pcodec](https://docs.rs/zarrs/latest/zarrs/array/codec/array_to_bytes/pcodec/index.html)...
> @d-v-b Instead, we use the kwarg "filters" to denote ArrayArray codecs I've just noticed that not all "filters" in Zarr V2 are ArrayArray codecs. For example, `vlen-*` codecs are...
Not at all, would you like to contribute such a feature? It looks like `moka` has an async cache, so it should be very easy to mirror the existing sync...
This would also close #266
This keeps coming up, so it'd be good to get this merged
Could be the switch to zstd by default?
> but I was able to read arrays lacking compression successfully in a web browser Awesome! The `Sync + Send` / `async_trait` changes look reasonable if you want to fire...
That is annoying, but here is an easy fix https://github.com/zarrs/zarrs/pull/248
That sounds reasonable, but we could just be patient. `zarr-python` might disallow it https://github.com/zarr-developers/zarr-python/issues/2855
> The rationale for this was to reach an eventual goal of having the xarray's CF decoding mechanisms represented completely as codecs so that non xarray clients using Virtualizarr stores...