Need to run through changes, document new workflow
WRT the updates to the specs: make a note (not comment) that it has been updated)
Deposit action from Gateway to Bridge
PUT object gateway call would have version header to indicate version - timestamps as version identifiers
Can assume that it creates a version with timestamp now
Doesn't make any difference as to what the repo does or doesn't do WRT versioning
Version is just a bag + timestamp
Current spec has ETag, could be timestamp -FLAG, also response headers for deposit
Repository maintains a mapping - fragile notion if DDP is supposed to recover repo
List only needs to be made known for the repository
Gateway interprets PUT as create version with timestamp
Info at the top-level, not with every single file - notion of object.
Versioning is from the level of object.
Update request body for each object
No versioning an option
What happens if I create 10 versions of a filegroup to bridge and then send restore request with no version specified?
Null version value
Need different ID on DDP side
Unalterability - requests to do non-version file changes is a no go
Generate new version if non supplied
What kind of response is requested if I send a request that would alter content?
Is it ok for the DDP to be the one that handles the idea of not overwriting things?
Versions within versions - DDP has concepts, Bridge has it's own, work independently of one another. Becomes complicated. Creates a situation where DDP level optimization, storing diffs, etc. become unavailable to the bridge.
Reject same object with the same version
Mapping from Gateway to Bridge to DDP versions.
Still need to dive in with the expectations of the DDP in mind
Next step: answer the question of what's the minimum spec for versioning for a DDP that supports versioning?
Spec as written with timestamp as version? Opaque or not?