Left TBD behind in Flow spec is resolved. Corresponding updates to Repository spec. Is this an adequate resolution? Yes. Note on cache - could just be a proxy pass through, 300-level response.
Service level description at top of Gateway API. JSON for describing.
PUT object has new request header specifying which storage classes/DDPs to post to. Resolves note at bottom. Storage class terminology comes out of AWS. Note that naming should be discussed later.
Versioning
Use case number 2. Repository to Gateway: this involves a number of PUT object requests.
In order to support this use case, the Gateway has to be able to accept a version parameter from the Repo. Need to pass that parameter to the Bridge and roundtrip it. Version parameter has to be semantical to reconstruct if Repo is lost.
Starting point: add version header to requests, see how that looks
Version header content semantics: ordinal numbers, date/timestamps. Date/timestamps follow other standards - Momento. Decision: date/timestamps.
Expectations on PUT header call from the repository to the Gateway uses timestamp. Don't pass a version? Is version required on all PUTS?
Restore request - get whatever's cached vs getting the latest version back.
Symmetrical headers across the board solve the problem. Assume exact matching.
List versions in place. Versions are understandable - IDs of filegroups and timestamps are understandable from Gateway and Bridge. "Give me a listing of all objects and all versions of those objects for a given repository."
Questions for next discussion
What is the recovery workflow for versions?
Spec changes needed
Gateway: PUT Object call will need a version header
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 file
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
Outstanding Questions
For each call, what is "default" if no version is provided?
What is the recovery workflow for versions?
If the Repository needs a file from a given date range (moment-style), will the Gateway be the place where the file to be restored is determined (e.g. retrieve list of versions, select most appropriate, perform restore call)?
Is there a need for the Bridge calls (Deposit/Delete/List) calls to associate versions with filegroups or is files sufficient? If filegroups are versioned, do files need to be; having both may cause confusion.
