Places:Sync: Difference between revisions
No edit summary |
|||
Line 6: | Line 6: | ||
* {{bug|374519}} - Sync client | * {{bug|374519}} - Sync client | ||
== Goals == | == PRD Goals == | ||
P1: | P1: | ||
Line 17: | Line 17: | ||
** sync bookmarks hierarchy | ** sync bookmarks hierarchy | ||
** sync tag data | ** 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 == | == 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(?). | |||
should support the following scenarios: | * Two-way sync should support the following scenarios: | ||
* initial: client has data, server has none | ** initial: client has data, server has none, or vice-versa | ||
* client changes: client has changes, server has no changes | ** client changes: client has changes, server has no changes | ||
* server changes: server has changes, cient has none | ** server changes: server has changes, cient has none | ||
* concurrent overlapping: same item changed on both client and server | ** concurrent overlapping: same item changed on both client and server | ||
* concurrent non-overlapping: different items changed on both client and server | ** concurrent non-overlapping: different items changed on both client and server | ||
== Design == | == 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 == | == Open Issues == |
Revision as of 02:24, 3 July 2007
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.