15th July, 2020

Attending: Alistair, Matthias, Dennis, Jon, Andrew, Martin

Apologies: Josh (bike tour),

• Regular v3 spec development call - trying to find a new time-zone-friendly time, please respond to this doodle if you’d like to attend

• v3 spec development process - straw man proposal - raise briefly for discussion

• https://github.com/napari/napari/ (some integration with Zarr during SciPy sprint)

• Issue for discussion of expanded character set for node names: https://github.com/zarr-developers/zarr-specs/issues/56 and see also discussion of case insensitivity in https://github.com/zarr-developers/zarr-specs/issues/57

  • Dennis: argues for supporting UTF8 in node names

  • Matthias: maybe zarr v3 spec could recommend that stores use the

    same normalisation, but don’t say exactly what normalisation

  • Dennis: getting stores to deal with encoding and normalisation

    seems OK. Maybe also recommend a normalisation. At least two different kinds of normalisation

  • [discussion of case insensitivity and mac file systems]

  • Alistair: in favour of requiring stores to be case sensitivity

  • Martin: mac case insensitivity is in file system driver

    (probably)

  • Dennis: in that case no way around, mac users with case

    insensitive file systems will have problems

  • Martin: agreed things will fail in some cases, but need to be

    more explicit about that will happen

  • Matthias: worried about recommending normalisation

• Gcsfs now has async bulk ops (including in the mapper get/set/delitems); http also done (read-only) and s3fs on the way. On master (needs master fsspec too).

  • Alistair: Any throttling of concurrent requests?

  • Martin: no.

  • […]

  • Matthias: context manager to indicate that a set of operations

    can be collected together?

  • Martin: fsspec does have idea of transaction.