Should there be a ZIP-per-version arrangement?

[zimeon]

The problem with ZIP-per-object is that we throw notions of immutability of past versions out of the window because one has to build a complete new zip to add a version. Version immutability could be recovered, along with easy access to the top-level inventory, with a ZIP-per-version arrangement, something along the lines of:

[object_root]
    ├── 0=ocfl_object_1.0
    ├── inventory.jsonld
    ├── inventory.jsonld.sha512
    ├── v1.zip
    └── v2.zip   

(not sure what naming should be, have put vN.zip as placeholder).

See also #181 discussion of object ZIP description.

[neilsjefferies]

Object zips are really intended for genuinely static stuff - like object snapshots dumped to tape.

Version zips do make some sense but potentially add some wrinkles. e.g. should we allow the zip files to included in the fixity section? It's potentially a lot quicker to check one zip vs lots of files.

[ahankinson]

we couldn't really store fixity of a zip file in the inventory, since the inventory in the root is a copy of the inventory in the version, and we wouldn't know the fixity value of the zip file before adding it in the inventory.

I'm not sure why we throw immutability of past versions out in the ZIP-per-object plan. It is possible to make a new zip file without touching the contents of previous versions.

I think @julianmorley was advocating for something like this earlier.

[rosy1280]

I feel like this is coming dangerously close to conversations about distributed versions and objects, something that we agreed to be out of scope for this version of the spec. is it possible to NOT include this example for this version (and therefore not have this conversation right now) and revisit it when for v 2 of the spec?

[ThomasEdvardsen]

Related Use-Case: OCFL/Use-Cases#33