SoC:RoamingSupport: Difference between revisions

 
(21 intermediate revisions by the same user not shown)
Line 7: Line 7:


=== The Sync Service ===
=== The Sync Service ===
This service will be the control center for sync updates and notifications. Classes who are interested in syncing would implement an observer interface (ex. <code>|nsIObserver|</code>). An interface would register itself based on the type of data that it uses. The Sync Service would handle all of the transactions between the observed data objects and the delta update messages.
A new service will be introduced into the mailnews component, called <code>nsIMsgRoamingService</code>. This service will delegate notifications between the data classes and roaming update messages. There are two paths of data through the roaming service, as illustrated below:


This service would also handle the dispatching of update messages. Ideally, another class would handle the gory details for message creation and maintenance of the delta messages and the full sync message.
Here is a high-level flowchart for the application events from and to the Sync Service:
<div style="text-align: center">[[Image:Flow_dataObjects.png]]</div>
<div style="text-align: center">[[Image:Flow_dataObjects.png]]</div>
Note: A "data class" is a interface that controls anything that we want synced, like an <code>|nsIMsgFolder|</code>.
Note: A "data class" is a interface that controls anything that we want synced, like an <code>|nsIMsgFolder|</code>.


=== Delta Update Messages ===
The roaming service uses the <code>nsIObserverService</code> to handle passing updates to the data classes. The designated topics for the roaming service can be found in <code>nsMsgRoamingConstants.h</code>.  
The idea of storage on either the IMAP or POP3 level involves the use of a complete sync message, and corresponding delta messages for each update since the last complete sync message.


We would like to store these messages somewhere other than the INBOX, and would like to avoid the end-user discovering these messages as much as possible. To hide these update messages in the IMAP implementation, we would probably take advantage of an un-subscribed folder. For the POP3 version, we would set some sinks in the POP3 protocol implementation to process our update message, and leave them out of the users inbox.
The roaming service also maintains the list of update messages that are stored on either the IMAP folder or the POP3 inbox. A typical set of update messages consists of one full update message, followed by a preset number of delta update messages. This setup is illustrated below:


To prevent any confusion, the subject of each delta message would be clearly labeled.  
<div style="text-align: center">[[Image:update_messages.png]]</div>


To prevent potential malicious emails from doing bad things during the update, we plan to sign our messages using a PIN implementation. This setup will be similar to the Google Sync feature.
=== Update Messages ===
For containing and controlling the data between installations, update messages are used to package and transport the sync data. All sync information is packed into a file. There are two types of update messages:


For keeping things simple, each update message will incorporate a TOC file. The format of the TOC file will look like:
* Full Update Message - Contains everything that the user has selected to sync
* Delta Update Message - Contains only the changes since the last full/delta update message.
 
Some of the sync data can be transferred as the full data file, like the address book's abook.mab file. However, certain data types like user preferences can not be sync'd this way, and contain an update log listed in the file. To help with unpacking all of the data, a TOC file is created and included with each update message. The format of the TOC file looks like this:


   NumItems: 3
   NumItems: 3
Line 30: Line 30:
   Item1: temp.txt
   Item1: temp.txt
   Item2: temp2.txt
   Item2: temp2.txt
This plain text format will make it easy for the roaming service to obtain attachments w/o having to run through libmime.


=== Delivery Options ===
=== Delivery Options ===
Line 49: Line 47:


For IMAP-synched sessions, a timer is probably not needed, as changes can be applied as new delta/update messages are posted. The same philosophy can be applied to the POP3 setting, applying sync changes based on the biff-update interval.
For IMAP-synched sessions, a timer is probably not needed, as changes can be applied as new delta/update messages are posted. The same philosophy can be applied to the POP3 setting, applying sync changes based on the biff-update interval.
== TODO List ==
To help keep things centralized, I'm keeping track of things I need to work on here. Any suggestions made by others will be listed here as well.
* Shutdown &amp; Refresh AB Datasource
* Mark Update Messages as Read (IMAP not working right?)
* Fix Purge Update Messages
* Initial/Temporary UI integration
* Sign Update Messages [file follow-up bug]
* Include information to setup a roaming account from a full update message.
* POP3 mailboxes that have a limited download size will fully download the entire update message
** [http://mxr.mozilla.org/mailnews/source/mailnews/base/util/nsMsgIncomingServer.cpp#1737 Use an internal filter].
** [http://mxr.mozilla.org/mailnews/source/mailnews/base/util/nsMsgIncomingServer.cpp#1629 Or read the filter from a file].


== Service Synchronization Notes ==
== Service Synchronization Notes ==
Line 64: Line 75:
** shutdown
** shutdown


== Things to keep in mind: ==
* Make the feature extensible
** A simple interface to inherit?
* Need a way to know that an object has changed
* A way to stream the object to a file, or a file pointer
** for newsrc files, filters, (anything that uses a file)
* Things that aren't stored as a file:
** Account Information
** About everything in account.js
*** Sync tag definitions
** An interface that parses and applies these changes:


----


== Item Synchronization Notes and Ideas ==
== Item Synchronization Notes and Ideas ==
26

edits