Jeremy Maitin-Shepard

I previously advocated against "version numbers" --- I'll reiterate the arguments I made in previous discussions: As the spec/format evolves, various new functionality will be added, and implementations will evolve...

As far as the issue of the chunk shape being affected by prior codecs (also applies if there is nested sharding), you are correct. I tried to fix the wording...

This is very similar to the kerchunk Reference File System format but is not exactly the same JSON format: https://fsspec.github.io/kerchunk/spec.html There are also at least a few implementations of the...

> > a few implementations of the kerchunk json format outside of kerchunk > > Can you please put references? They might be useful for inspiration. I updated my comment...

@martindurant Is there a document that describes the kerchunk parquet format?

While we can all assume what `s3://` means, in order for this to be fully specified, we also need to specify the meaning of the URLs. See https://github.com/zarr-developers/zeps/pull/48 for one...

Another issue to consider is the [Confused deputy problem](https://en.wikipedia.org/wiki/Confused_deputy_problem): user A might think they are writing to "s3://someone-elses-bucket/path" but actually end up writing with user A's credentials to "s3://user-a-private-bucket/other/path". Similarly,...

> No, but I could make one. I think that would be very helpful.

> @jbms - I have a few answers to your question of "why not use the kerchunk format": > > * Kerchunk represents the entire store as a single manifest,...

As I see it, this "manifest" format could be used as a key-value store adapter independent of zarr entirely, as a transparent layer below zarr that is not explicitly indicated...