SoC:RoamingSupport

The Proposal

My initial idea is to create a new interface that registers itself as a service with XPCOM. This service will allow objects to register (and unregister if needed) themselves for synchronization push and pull operations. This interface will also provide at least a high-level path for wrapping up the data to sync in a sudo-email message or IMAP implementation.

The push operations would provide the object a new set of data (in a to-be-determined data structure) and leave the implementation details up to the object.

The pull operation would request data (again in a to-be-determined structure) from the object into the synchronization 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. |nsIObserver|). 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.

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:

Note: A "data class" is a interface that controls anything that we want synced, like an |nsIMsgFolder|.

Delta Update Messages

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.

To prevent any confusion, the subject of each delta message would be clearly labeled.

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.

For keeping things simple, each update message will incorporate a TOC file. The format of the TOC file will look like:

 NumItems: 3
 Item0: mbook.ab
 Item1: temp.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

The delivery mechanism should anonymous from the details of the actual storage of the message, wether it be IMAP or POP3. The sync service should be able to pass down something like a file pointer to a temporary sync file. The advantage to storing the updates in an individual file is to keep away from the actual "live" data files, and perhaps create the ability to format the update file in a format of our choosing.

At this stage, we have not determined if the storage options in the delta messages, here are the options I have come up with so far:

• Store all updates for current iteration in one file
• Store each update in an individual delta message
• Store each individual update as individual files in one delta iteration.

The full sync message would contain a renamed zip archive (.zim or whatever) to help preserve with storage space. The message would also be marked not to delete on the server side.

Syncing Sessions

To help preserve the integrity of the sync, a "sync-log" has been proposed to keep track of all of the changes that have been applied (and probably when they were applied).

Since shutting down and not syncing would probably suck for the average user, I have planned to add a pref that allows forced synchronization at shutdown. Either the user can build and save our build send the message depending on the pref.

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.

Service Synchronization Notes

• Items to Sync:
  • Address Book
  • Mail Filters
  • Saved Searches
  • Newsrc files
  • Rss subscriptions
  • Tag definitions
  • Views
  • etc.. (add more)
• When to sync?
  • on a set interval (pref?)
  • 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

Below contains notes for potential hooks for notifying an interface (service possibly) that an object has changed and needs to be synced. These locations might also be ideal for points of entry where the notifying interface could inform the object of changes from an external source.

Address Book

• Some object that extends from |nsIAbListener|
  • |nsAbDirectoryDataSource|
  • |nsAbView|

Message View Synchronization Ideas

|nsMsgMailViewList| seems like the best place from just poking around. I could just set some sinks in that class for when methods like |AddMailView()| and |RemoveMailView()| are called.