Skip to main content Link Search Menu Expand Document (external link)

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.