Jeremy Maitin-Shepard

It occurred to me that concatenation could be supported as an array -> bytes codec in conjunction with ZEP 3 (variable-size chunks): The codec (maybe called `zarr_reference` or something like...

> Some things that came up in the ZEP meeting today: > > 1. Concatenation and (range-)indexing are in some sense inverse operations of one another, so including them together...

I imagined that the json object would be essentially interchangeable with a path/url to a stored zarr array, and could therefore be passed directly to e.g. `zarr.open` but could also...

As Ryan noted, we've had a lot of discussions about attributes and a number of solutions have been proposed but no consensus has yet been reached. I think it may...

I think you will have to decide yourself whether your comments are closely related to one of the existing issues. I don't think there is existing an issue specifically related...

> > When using sharding as a codec, the implementation **must** use partial reads to be able to read single chunks. > > I wouldn't see it that way. Partial...

> The spec does not explicitly say that `array` has to be a dense numpy-style array. So in principle we can have a codec that takes an arbitrary buffer (however...

> * As @ivirshup said, the pointers, indices, and values often have different dtypes and therefore should be stored as independent (chunked) objects. This does seem similar to an `xarray`...

This requirement would preclude use of the filesystem store (without escaping) with normal local filesystems on macos and windows. Instead it should be defined by the store/implementation.

Escaping could be a solution, but it would essentially amount to a separate incompatible store, and would sacrifice readability of the keys.