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?
Bill's notes
Gateway: PUT Object call will need a version header - Timestamp as version identifier - Gateway interpretes this as "make me a version at this timestamp" with the bag provided. - If you put that version, you'll be able to get it back - Repository PUTs and object/work in its entirety to the Gateway - Doesn't matter what the repository does as far as versioning on its own - The PUT doesn't need a version header - Gateway adds a call to get a list of all versions for an Object Gateway: DELETE Object call will need a version header Gateway: POST Object Restore call will need a version header Gateway: A new endpoint will be needed to retrieve a listing of deposited objects and associated versions (to support the rebuild use case)
Bridge: Deposit Content call will need to support version value for each filegroup - If no version is provided, then it's the only version - If the object is sent again, that's an overwrite - The Bridge considers the version value opaque, doesn't try to understand meaning - The "null" version value is the same as any other version Bridge: Delete Content call will need to support version value for each file Bridge: List Deposited Content will need to support version value for each file Bridge: Restore Content call will need to support version value for each file
