Jeremy Maitin-Shepard

I don't think my own involvement in reviewing this proposal is sufficient to be listed as a collaborator. I actually would still very much welcome some clarifications about precisely how...

The spec does say that `fallback` may be a list of data types: https://github.com/zarr-developers/zarr-specs/blob/cdf97c94d9e6f13dc820a0cd604cc8f9b0d61d03/docs/v3/core/v3.0.rst?plain=1#L494 Note though, that in regard to fallback data types, there is an outstanding issue of how...

A key point that came up in the discussions was that typically when listing the contents of a zarr hierarchy, you will most likely want more information than just whether...

> "When listing the contents of a zarr hierachy..." Agreed, But one use case we have is lazy loading of arrays. In that case, we need to locate where the...

Could you add a new API function that returns the list of all members, sub-groups and arrays, and recommend that users call that instead for greater efficiency when using zarr...

If there is one API function that lists both arrays and groups, and just returns a flat list of names without indicating which are arrays and which are groups, then...

Agreed that none of the existing "extension points" are applicable for this purpose. However, at least as I see it, an "extension" more generally is really any future change to...

Yes, perhaps it should be clarified. It seems to me that a typical approach for creating an extension would be to first create an (experimental) implementation, then create a ZEP...

That is a good point. Currently the spec does not specify this, and therefore it is left up to the definition of the specific configuration, and currently those aren't very...

If I understand correctly, really what you are looking for is a key value-store adapter that handles versioning, snapshots, possibly packs things into a smaller number of files, and avoids...