Context Navigation

P2PSync

Timestamp:: 05/30/17 17:07:16 (8 years ago)
Author:: MichaelRogers
Comment:: --

Legend:

: Unmodified
: Added
: Removed
: Modified

BluePrint/Mobile/P2PSync

-              v14
+              v15
 ==== 1. Synchronize immutable documents ====
 In this option, the data to be synced consists of immutable documents, each of which originates on one mobile device and is synced to other devices without being modified. Examples of immutable documents might include a completed form or a photo.
+In this option, the data to be synced consists of immutable documents, each of which originates on one mobile device and is synced to other devices without being modified. Examples of documents might include a completed form or a photo.
 Detecting and resolving conflicts is simple in this option: each data item is identified by its cryptographic hash, which ensures that if two items have the same identifier then they also contain the same data.
+Detecting and resolving conflicts is simple in this option: each data item is identified by its cryptographic hash, which ensures that if two items have the same identifier then they also contain the same data. Therefore from the point of view of the sync protocol, conflicts are always avoided.
 This option also makes it simple for data to be encrypted on the originating device and decrypted on the destination server.
+This option allows documents to be encrypted on the originating device and decrypted on the destination server.
 The destination server confirms delivery of an immutable document by creating a delivery confirmation containing the document's identifier, signed with the server's OpenPGP key. The confirmation can be synced between mobile devices, which can delete the confirmed document if they no longer need a local copy.
+The destination server confirms delivery of a document by creating a delivery confirmation containing the document's identifier, signed with the server's OpenPGP key. The confirmation can be synced between mobile devices, which can delete the confirmed document if they no longer need a local copy.
 ==== 2. Synchronize changes to database records ====
 …
 Detecting and resolving conflicts in this option follows a similar approach to [http://docs.couchdb.org/en/2.0.0/intro/consistency.html CouchDB]. Non-conflicting updates are applied automatically. If a conflict occurs, the P2P sync component stores all conflicting versions of the record and asks the application to resolve the conflict, which may require user intervention, either on the mobile device or on the destination server.
 This option allows individual database fields to be encrypted on the originating device and decrypted on the destination server, but if a conflict occurs in an encrypted field it may not be possible to resolve it on the mobile device.
+This option does not allow records to be encrypted on the originating device and decrypted on the destination server. Individual fields can be encrypted, but if a conflict occurs in an encrypted field it may not be possible to resolve it on the mobile device.
 The destination server confirms delivery of a record by creating a delivery confirmation containing the record's identifier and [https://wiki.apache.org/couchdb/Replication_and_conflicts revision], signed with the server's OpenPGP key. The confirmation can be synced between mobile devices, which can delete the confirmed record if they are storing the same revision and no longer need a local copy. Multiple revisions of a given record may be confirmed by the destination server.
+The destination server confirms delivery of a record by creating a delivery confirmation containing the record's identifier and [https://wiki.apache.org/couchdb/Replication_and_conflicts revision], signed with the server's OpenPGP key. The confirmation can be synced between mobile devices, which can delete the confirmed record if they are storing the same revision and no longer need a local copy (they must keep the record if they are storing a different revision). Multiple revisions of a given record may be confirmed by the destination server.
 ==== Comparison of the options for each use case ====
 The immutable documents option would be well suited to the "Situation Reporting and Assessment" and "Self-Organized Canvassing" use cases, which are primarily concerned with collecting data and delivering it to a central server.
 The "Aid Distribution" use case involves updating information as well as collecting it: for example, recording the fact that an individual who was previously eligible for aid has now received it. The database records option would be well suited to this use case, but it could also be handled with immutable documents by using a log structure: a log of documents representing events would be attached to each document representing an individual.
+The "Aid Distribution" use case involves updating information as well as collecting it: for example, recording the fact that an individual who was previously eligible for aid has now received it. The database records option would be well suited to this use case, but the use case could also be handled with immutable documents by using a log structure: a log of documents representing events would be attached to a document representing an individual, for example.
 The "Logistics Management" use case is primarily concerned with managing mutable information. This would be possible with immutable documents by using a log structure, but for efficiency it would probably also be necessary to maintain a representation of the current state. The complexity of maintaining two representations of the data might make the database records option preferable for this use case.
+The "Logistics Management" use case is primarily concerned with managing mutable information. This would be possible with immutable documents using a log structure, but for efficiency it would probably also be necessary to maintain a representation of the current state. The complexity of maintaining two representations of the data might make the database records option preferable for this use case.
 === Data Model ===
 …
 == Current Implementation ==
-None.
 == Planned Implementation ==