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 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.
Two-way sync
One option is sayrer's sync.js (bug 37917). That implements a simple log-less 3-way merge.
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
- Thunderbird's roaming support is an SOC project dealing w/ vaguely similar sync scenarios.