Collection update API » History » Version 1

Peter Amstutz, 05/18/2015 09:13 PM

1 1 Peter Amstutz
h1. Collection update API
2 1 Peter Amstutz
3 1 Peter Amstutz
Problem: adding, updating, renaming, or removing a file in a collection requires sending the entire manifest text of the collection.  This approach creates two problems:
4 1 Peter Amstutz
5 1 Peter Amstutz
# It is inefficient; resources are wasted transferring and processing manifest data that hasn't changed 
6 1 Peter Amstutz
# It creates a race condition; for example processes A and B read the collection record at time T1, merge it with their local updates, process A sends its update at time T2, process B sends its update at time T3, then in process A's updates are lost.
7 1 Peter Amstutz
8 1 Peter Amstutz
Proposed solution: introduce new 'update' or 'patch' endpoint for collections supporting a patching protocol allowing incremental collection update.
9 1 Peter Amstutz
10 1 Peter Amstutz
The protocol consists of an *operation* field with values of *add*, *remove* or *modify*.
11 1 Peter Amstutz
12 1 Peter Amstutz
Each operation has parameters *initial_contents*, and *final_contents*.  The *contents* fields contain normalized manifests with exactly one file.  The stream and file name are put together to get the name of the file that is affected by the operation.
13 1 Peter Amstutz
14 1 Peter Amstutz
An *add* operation adds a new file represented by *final_contents*.  The *initial_contents* should be empty or unspecified.  If there is already a file with that name and the existing file has different contents, the existing file should be uniquely renamed to indicate that it is in conflict, and the new file takes its place.
15 1 Peter Amstutz
16 1 Peter Amstutz
An *remove* operations adds