Places:Sync: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
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 ==


* all bookmark and tag data must by sync-able.
Note that requirements will vary depending on the features we decide on.


* client api should allow server-dictated external authentication mechanisms, such as HTTP auth or browser-based auth.
* 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.


* client api should allow extension data attached to bookmarks/folders/tags be synced as well (maybe just through annotations?).
* 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 ==


== Implementation ==
=== 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 ===


* XXX provide info about sayrer's sync.js
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:

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.