Revision c9aba6cc
| b/docs/source/devguide.rst | ||
|---|---|---|
| 25 | 25 |
========================= ================================ |
| 26 | 26 |
Revision Description |
| 27 | 27 |
========================= ================================ |
| 28 |
0.7 (Sept 22, 2011) Suggest upload/download methods using hashmaps. |
|
| 28 |
0.7 (Sept 28, 2011) Suggest upload/download methods using hashmaps. |
|
| 29 |
\ Propose syncing algorithm. |
|
| 29 | 30 |
0.6 (Sept 13, 2011) Reply with Merkle hash as the ETag when updating objects. |
| 30 | 31 |
\ Include version id in object replace/change replies. |
| 31 | 32 |
\ Change conflict (409) replies format to text. |
| ... | ... | |
| 437 | 438 |
x_object_manifest Object parts prefix in ``<container>/<object>`` form (optional) |
| 438 | 439 |
x_object_sharing Object permissions (optional) |
| 439 | 440 |
x_object_shared_by Object inheriting permissions (optional) |
| 441 |
x_object_allowed_to Allowed actions on object (optional) |
|
| 440 | 442 |
x_object_public Object's publicly accessible URI (optional) |
| 441 | 443 |
x_object_meta_* Optional user defined metadata |
| 442 | 444 |
========================== ====================================== |
| ... | ... | |
| 1055 | 1057 |
|
| 1056 | 1058 |
Consulting hashmaps when downloading allows for resuming partially transferred objects. The client should retrieve the hashmap from the server and compare it with the hashmap computed from the respective local file. Any missing parts can be downloaded with ``GET`` requests with the additional ``Range`` header. |
| 1057 | 1059 |
|
| 1060 |
Syncing |
|
| 1061 |
^^^^^^^ |
|
| 1062 |
|
|
| 1063 |
Consider the following algorithm for synchronizing a local folder with the server. The "state" is the complete object listing, with the corresponding attributes. |
|
| 1064 |
|
|
| 1065 |
:: |
|
| 1066 |
|
|
| 1067 |
L: local state (stored state from last sync with the server) |
|
| 1068 |
C: current state (state computed right before sync) |
|
| 1069 |
S: server state |
|
| 1070 |
|
|
| 1071 |
if C == L: |
|
| 1072 |
# No local changes |
|
| 1073 |
if S == L: |
|
| 1074 |
# No remote changes, nothing to do |
|
| 1075 |
else: |
|
| 1076 |
# Update local state to match that of the server |
|
| 1077 |
L = S |
|
| 1078 |
else: |
|
| 1079 |
# We have local changes |
|
| 1080 |
if S == L: |
|
| 1081 |
# No remote changes, update the server |
|
| 1082 |
S = C |
|
| 1083 |
L = S |
|
| 1084 |
else: |
|
| 1085 |
# Both we and server have changes |
|
| 1086 |
if C == S: |
|
| 1087 |
# We were lucky, we did the same change |
|
| 1088 |
L = S |
|
| 1089 |
else: |
|
| 1090 |
# We have conflicting changes |
|
| 1091 |
resolve conflict |
|
| 1092 |
|
|
| 1093 |
Notes: |
|
| 1094 |
|
|
| 1095 |
* States represent file hashes (either MD5 or Merkle). Deleted or non-existing files are assumed to have a magic hash (e.g. empty string). |
|
| 1096 |
* Updating a state (either local or remote) implies downloading, uploading or deleting the appropriate file. |
|
| 1097 |
|
|
| 1058 | 1098 |
Recommended Practices and Examples |
| 1059 | 1099 |
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 1060 | 1100 |
|
Also available in: Unified diff