SoC:RoamingSupport

Service 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 a 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.

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 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.

Delivery

• Build a message w/ attachments
  • Used for both IMAP and Mail delivery cases

Service Synchronization Notes

• Items to Sync:
  • Address Book
  • Mail Filters
  • Saved Searches
  • Newsrc files
  • 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.