> This sounds really awesome. Especially being based on XMPP - this goes
> one step further than Mozilla Weave, which uses polling (but is
> otherwise a great project).

> I have one question, which I didn't see answered in the design doc.
> Will the data be encrypted client-side? This is a must for passwords
> synchronization (which is the most useful sync type for me
> personally). And is password synchronization on the roadmap at all?

> - Peter

> On Aug 1, 12:07 am, Tim Steele <t...@chromium.org> wrote:
> > Hi!

> > A bunch of us have been working on a feature to sync user data in
> Chromium
> > with a Google account.  (Surprise! :))  The great news is that we'll be
> > starting to work directly in the Chromium project this week, and let me
> tell
> > you, are we excited to do that!  This email discusses how we're planning
> to
> > get started, in detail (maybe too much detail... sorry).

> > We have built a library that implements the client side of our sync
> > protocol<
> http://sites.google.com/a/chromium.org/dev/developers/design-document...>,
> > as well as the Google server-side infrastructure to serve Google Chrome
> > users and synchronize data to their Google Account.  Of course, all the
> code
> > going into Chromium is open source, and the messages between the client
> and
> > server use the open protobuf <http://code.google.com/p/protobuf/> format
> and
> > library.  Check out the sync developer
> > page<
> http://sites.google.com/a/chromium.org/dev/developers/design-document...>
> > if
> > you're interested in low-level goals and technical details.

> > We will be landing this code in a few steps rather than one giant
> changelist
> > for a number of reasons.  First, this makes reviewing a *lot* easier; it
> > isn't the most straightforward code by nature, so the more fine grained
> > scrutiny the code gets, the better.  Second, we've been working in a
> > proprietary environment until now because of the dependency of having to
> > build the complementary Google production server environment for syncing.
> >  As such, the code uses a small number of internal libraries that we need
> to
> > open-source or replace, as well as libraries that would be redundant to
> what
> > Chromium already includes.  Removing these, and open sourcing the entire
> > sync engine, is our highest priority and we expect this to take about
> three
> > weeks.

> > So how will we commit the code in pieces and not totally hose the build
> in
> > the process?  First, a little more background.  You may have come across
> the
> > CHROME_PERSONALIZATION #define when digging through Chromium source code.
> >  Right now, this is used in conjunction with a relatively small number of
> > private c++ source files to conditionally build Chromium with sync
> enabled.
> >  These files are in fact a glue layer between Chromium and what is called
> > the "syncapi", which is the bulk of the client library I was talking
> about
> > above.  On windows, syncapi is built into a DLL, and when
> > CHROME_PERSONALIZATION is defined this DLL gets placed alongside
> chrome.dll
> > for use at runtime.  Syncapi builds and runs on Linux, but not Mac (yet).

> > With the initial checkin, we will leave the CHROME_PERSONALIZATION
> #define
> > as-is, so the sync code will not be built by default.  We'll be working
> hard
> > over the coming weeks to make sure the code passes all existing test
> suites
> > that are part of the regular buildbot cycle, and on removing the #define.
> >  After that, our hope is that we will be free of the DLL altogether and
> have
> > all the code checked in to the repository, fully functional or not, in a
> few
> > weeks.  We do *not* plan on ever checking in the windows-only syncapi dll
> to
> > the main chromium repository.  So until the dll is no longer needed, the
> > public repository won't have all the bits to actually build Chromium with
> > sync enabled.  That said, we want to keep the sync build running
> smoothly,
> > so we will use a combination of command-line flag (to enable sync) and
> > delay-loading syncapi.dll only when it is needed.  This will allow the
> > "glue" code to compile as part of the normal Chromium build without
> > introducing a dependency on this dll, yet still make it possible to run
> with
> > the dll present.

> > On that note, we're planning to use the syncapi DLL to produce a
> > sync-enabled Google Chrome build for dev-channel users in a week or so,
> to
> > get the feature into experimentally inclined hands.  We have a great deal
> of
> > infrastructure, both in the browser and in the form of production Google
> > services, that need to start seeing real user traffic and usage.  It
> takes a
> > great deal of testing and confidence inspired by real usage statistics
> > before any complex system like this can be deemed adequate for use by a
> > large user base.  So if we want to let all Google Chrome users use sync
> (and
> > we do! we do!), we've got to get started on this pronto.

> > Our developer page<
> http://sites.google.com/a/chromium.org/dev/developers/design-document...>
> > also
> > covers the hierarchy of files we're landing that you can expect to start
> > syncing (in the gclient sense) down in the next couple of days.  We can't
> > wait (*really*) to work on this with the rest of the Chromium community
> and
> > going even further in creating the best browzr ever!

> > Thanks for reading, and happy syncing!

> > - the cloudy bunch
> > {idana, nick, nickbaum, chee, munjal, brg, chron, zork, laforge,
> tejasshah,
> > tim} at chromium.org