Places:Sync

Active Work

Bugs:

• bug 374518 - Platform support
• bug 374519 - Sync client

PRD Goals

P1:

• Provide the platform-level support required for sync extensions

P2:

• Sync Client
  • sync bookmarks hierarchy
  • sync tag data

Proposed Firefox 3 Features

Various combinations of the following options have been proposed for Firefox 3 (roughly in order of difficulty):

• Online bookmarks backup: One-way bookmarks backup at regular intervals to a remote site of the user's choosing. This should be relatively easy to implement after we have a more modern serialization format (we'd want to move away from bookmarks.html).

• Sync service registration: Standardized UI to keep track of sync service providers and any settings required for them. i.e., account username, password, sync url, etc.

• Sync client services for extensions: Two-way services included in some fashion, to help sync extensions and promote a similar sync experience among different extensions. Probably not worth considering, except as a stepping-stone to the next

feature--

• Built-in (2-way) sync: Full two-way sync with UI, likely with service registration to seamlessly support multiple services.

Requirements

Note that requirements will vary depending on the features we decide on.

• All user-defined bookmark and tag data should be serialized.

Exceptions might include very large annotations(?). Automatically generated annotations (e.g., from an extension that saves web page "screenshots" as annotations) should not be serialized for backup or sync.

• Authentication methods for backup and sync should include at least

basic and digest auth, and we should consider requiring ssl(?).

• Two-way sync should support the following scenarios:

• • initial: client has data, server has none, or vice-versa
  • client changes: client has changes, server has no changes
  • server changes: server has changes, cient has none
  • concurrent overlapping: same item changed on both client and server
  • concurrent non-overlapping: different items changed on both client and server

Design

Online backup

This would consist of a service which would keep track of the locations to upload to and trigger the uploads at regular intervals. It should observe the bookmark events and supress the upload if nothing has changed since the last upload.

The file to upload should be a serialized version of the bookmarks data, format TBD. Possibly JSON. Much of this code can probably be shared with the next-gen bookmarks file format exporter that will replace bookmarks.html.

Registration hooks

This depends on what kind of information we want to save about each service. This data could be stored in the places db perhaps? At the very least it should contain a name and a url.

If we implement this, we'll also want easy ways for the user to get services added to the list. E.g., by downloading a file from the service itself which adds it to the list, much like search plugins work.

We should also consider having wizards that guide the user through setting up their backup/sync from scratch to provide a seamless experience, instead of the user having to add a service first and add folders to sync later. We'll have to square that off with some services supporting multiple shared folders.

Note that registration is desirable regardless of the level of sync support we ship with by default--one way (backup) or two way (full sync).

Two-way sync

One option is sayrer's sync.js (bug 379517). That implements a simple log-less 3-way merge. There is a sample implementation of two-way sync using sync.js in (bug 374518).

Another possibility is to log each action the user makes (by attaching observers to all the bookmarks commands). The client would keep a log of all actions and reconcile them with the server on sync. This is similar to sync.js, except that sync.js deduces the actions from the data instead of keeping track of edits.

It should also be possible to extend the "online backup" feature by optionally downloading a file with edits to the local computer after completing the upload. This would give the server the possibility to implement sync if they wish.

Open Issues

• sync all item annotations?
• security review of json on-the-wire, eval sandbox
• which external authentication mechanisms supported?
• flesh out the web service choreography
• what are the primitives? how do services specify what sync data they support?
• how do sync handlers get installed, registered, etc? new content handling framework?

local sync/access:

• ipc
• dbus
• spotlight
• google desktop
• local webserver

Related Links

• Wikipedia browser sync matrix

• Thunderbird's roaming support is an SOC project dealing w/ vaguely similar sync scenarios.