The Chromium Projects
 
Search this site

Except as otherwise noted, the content of this page is licensed under a Creative Commons Attribution 2.5 license, and examples are licensed under the BSD License.

The Chromium OS designs and code are preliminary. Expect them to evolve.
For Developers‎ > ‎Design Documents‎ > ‎

Sync

[ check back soon for updates!  We're just getting started here. ]

Who

Idan Avraham (idana)         Nick Carter (nick)
Munjal Doshi (munjal)        B. Green (brg)
Jonathan Huang (chron)     Tim Steele (tim)
Zach Kuznia (zork)

Anthony Laforge (laforge)   Nick Baum (nickbaum)
Tejas Shah (tejasshah)      Chee Chew (chee)

with special thanks to:

Andrew de los Reyes (adlr)     
Ryan Cairns (rtc)
Peter Bradshaw (bradshaw)    
Chris Masone (cmasone)
Jeffrey Rennie (rennie)            
Kan Liu (kanliu)
Eric Uhrhane (ericu)             

What

A library that implements the client side of our sync protocol, as well as the Google server-side infrastructure to serve Google Chrome users and synchronize data to their Google Account.

The goals for this protocol include:
  • Store/sync user's bookmarks in a way that may be extended to additional data types.
  • Allow the user to connect to the server from multiple clients simultaneously.
  • Changes the user makes in one client should be immediately reflected in other clients connected to the server.
  • Allow the user to make changes to her bookmarks even if the server is unreachable, such that changes made while offline are synced with the server at a later time.
  • Resolve bookmark data conflicts on the client without prompting the user.
  • Provide a web interface to access stored / synced bookmarks, likely via the docs.google.com doclist.
  • Standards compliant (e.g xmpp) client/server messaging.
Where

The code lives in the Chromium repository, and is rooted at chrome/browser/sync.

chrome/browser/sync/ 

Top level directory containing the entry point used by other chrome code, such as profile.h.
For example, profile_sync_service.h/cc


The rest of this stuff will live in 'browser_sync' namespace.

...sync/glue

Stuff needed to embed the engine into Chrome.
For example,
  •   http_bridge.h/cc - a bridge from the sync engine into Chrome's HTTP stack.
  •   bookmark_model_worker.h/cc - makes sure the BookmarkModel is only used on the UI loop,
      even though the engine runs on it's own thread.
...sync/engine 

This will be the ultimate home of the full source for our sync engine.  Currently, this code uses proprietary libraries which should be replaced with (or open sourced themselves) open source libs.  We'll be adding things here shortly, but for now this only contains the sync engine entry point, syncapi.h.

...sync/syncable

The domain of all things syncable on the client.  The definitions of what a bookmark or a folder look like in sync-land, as well as the code responsible for maintaining the local cache of the cloud state, are found in here. The code to persist the local cache using sqlite is also found here.

...sync/protocol

Contains our protobuf specification of the messages sent between clients (the browser) and sync servers.

When

Our roadmap for the forseeable future is below.  The list is in prioritized chronological order with work estimates in total weeks from Aug 3.

  1. Check in glue code to chromium with #ifdef CHROME_PERSONALIZATION still intact.  May rename this shortly afterwards to CHROME_SYNC to be more clear.
  2. Eliminate any regressions and get all primary Chromium buildbot tests and test suites (e.g valgrind) passing with CHROME_PERSONALIZATION defined.  [ETA: ~1 - 2 wks]
  3. Remove the #define so that the code is built by default.
  4. Finish porting the rest of the core sync engine into the Chromium project. [ETA: ~3 weeks].
  5. Remove syncapi.dll and link statically with chromium.
  6. Push a sync-enabled build to the dev-channel using an --enable-sync command line flag to turn on the feature.
  7. Write the rest of the roadmap!
How

[TODO(tim): Add useful information here.]
To make this sync infrastructure scale to millions of users, we decided to leverage existing XMPP-based Google Talk servers to give us "push" semantics, rather than only depending on periodically polling for updates.  This means when a change occurs on one Google Chrome client, a part of the infrastructure effectively sends a tiny XMPP message, like a chat message, to other actively connected clients telling them to sync.  To put that gain into perspective, consider a 3 minute polling interval.  3 minutes is far from real time, or "immediately" as our goal was stated.  But already, at the very least, every 3 minutes every client needs to ask the server if anything changed.  Even with just one thousand users, we're already talking about a server having to handle a poll request every 0.18 seconds on average (or roughly 5.6 queries per second). And that's just when nothing is happening! Using XMPP pushes, the sync servers don't need to waste cycles for no reason.