Find your local number:


Discussion items


Versioning, sweet versioning
  • 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

Action items