Changes between Version 14 and Version 15 of BluePrint/Mobile/P2PSync


Ignore:
Timestamp:
05/30/17 17:07:16 (7 years ago)
Author:
MichaelRogers
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • BluePrint/Mobile/P2PSync

    v14 v15  
    9393
    9494==== 1. Synchronize immutable documents ====
    95 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.
     95In 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.
    9696
    97 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.
     97Detecting 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.
    9898
    99 This option also makes it simple for data to be encrypted on the originating device and decrypted on the destination server.
     99This option allows documents to be encrypted on the originating device and decrypted on the destination server.
    100100
    101 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.
     101The 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.
    102102
    103103==== 2. Synchronize changes to database records ====
     
    106106Detecting 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.
    107107
    108 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.
     108This 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.
    109109
    110 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.
     110The 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.
    111111
    112112==== Comparison of the options for each use case ====
    113113The 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.
    114114
    115 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.
     115The "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.
    116116
    117 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.
     117The "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.
    118118
    119119=== Data Model ===
     
    179179
    180180== Current Implementation ==
    181 None.
    182181
    183182== Planned Implementation ==