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 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
According to that webpage, this currently only syncs bookmarks. More data types may come some day. (Personally, I hope they do. I'm more interested in history/visited link/omnibox syncing than bookmarks.)
So we are going to tie up Chromium sync to just Google Services? Why not
make the protocol open so any service could use it. So if anyone wants to
sync, they will install an extension to do so, instead of coupling it
directly to Google services.
-- Mohamed Mansour
> According to that webpage, this currently only syncs bookmarks. More data
> types may come some day. (Personally, I hope they do. I'm more interested
> in history/visited link/omnibox syncing than bookmarks.)
On Fri, Jul 31, 2009 at 3:04 PM, Mohamed Mansour <m...@chromium.org> wrote: > So we are going to tie up Chromium sync to just Google Services? Why not > make the protocol open so any service could use it.
The protocol _is_ open. Protobufs are open source and the sync spec built on them is also open source.
Yep, what Peter said. In the coming weeks, we will check in the full protocol definition itself, which is what we used to build the Google service for Google Chrome users.
On Fri, Jul 31, 2009 at 3:05 PM, Peter Kasting <pkast...@google.com> wrote: > On Fri, Jul 31, 2009 at 3:04 PM, Mohamed Mansour <m...@chromium.org> wrote:
>> So we are going to tie up Chromium sync to just Google Services? Why not >> make the protocol open so any service could use it.
> The protocol _is_ open. Protobufs are open source and the sync spec built > on them is also open source.
On Fri, Jul 31, 2009 at 6:08 PM, Tim Steele <t...@chromium.org> wrote:
> Yep, what Peter said. In the coming weeks, we will check in the full > protocol definition itself, which is what we used to build the Google > service for Google Chrome users.
> On Fri, Jul 31, 2009 at 3:05 PM, Peter Kasting <pkast...@google.com>wrote:
>> On Fri, Jul 31, 2009 at 3:04 PM, Mohamed Mansour <m...@chromium.org>wrote:
>>> So we are going to tie up Chromium sync to just Google Services? Why not >>> make the protocol open so any service could use it.
>> The protocol _is_ open. Protobufs are open source and the sync spec built >> on them is also open source.
On Fri, Jul 31, 2009 at 3:59 PM, Caleb Eggensperger <caleb...@gmail.com>wrote:
> The doc says:
> - Provide a web interface to access stored / synced bookmarks, likely > via the docs.google.com doclist.
> What about google.com/bookmarks? Shouldn't be difficult -- toolbar syncs > to there currently.
It's more difficult than you'd think. Chrome's different data model, among other things, make it a lot like the "square peg in a round hole" problem. But it's something we're looking into. For the first release, we've just focused on getting sync to work between Chrome instances.
This is really, really cool.I was positive you will not implement this as a
core feature, but expand the extensions system to support that instead
(which kind of makes sense).
Will there be an option to sync to a different server?
Maybe others would like to create their own community cloud.
On Sat, Aug 1, 2009 at 02:38, Tim Steele <t...@chromium.org> wrote:
> On Fri, Jul 31, 2009 at 3:59 PM, Caleb Eggensperger <caleb...@gmail.com>wrote:
>> The doc says:
>> - Provide a web interface to access stored / synced bookmarks, likely
>> via the docs.google.com doclist.
>> What about google.com/bookmarks? Shouldn't be difficult -- toolbar syncs
>> to there currently.
> It's more difficult than you'd think. Chrome's different data model, among
> other things, make it a lot like the "square peg in a round hole" problem.
> But it's something we're looking into. For the first release, we've just
> focused on getting sync to work between Chrome instances.
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:
> 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 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
That's awesome.
The dev build you are talking about, it will be a fully functional
version, right?
Do you have any predictions for getting sync in beta channel?
-- Max
On Aug 1, 12:07 am, Tim Steele <t...@chromium.org> wrote:
> 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 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
We are planning to use HTTPS for the sync traffic so that any sensitive
information stored in bookmarks is protected when sent over the wire.
Bookmarks are not going to be encrypted on the client before they are sent
to the server, though.
We are aware of the fact that passwords and other browser data types is
something we'll need to think about at some point. We wanted to focus on
bookmarks and get it right first before we think about other data types. We
chose bookmarks both because they are generally the most important to users,
but also because they are the hardest data type to sync since we have to
sync an entire hierarchy of folders/bookmarks and there are tons of
difficult edge cases involved in doing that (e.g. what happens when two
changes from two different clients result in a loop in the bookmark
hierarchy).
On Sat, Aug 1, 2009 at 5:46 AM, Peter Petrov <onest...@gmail.com> wrote:
> 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 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!
On Fri, Jul 31, 2009 at 14:07, 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 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
When we fully land the sync code (hopefully in the coming few weeks),
developers will certainly be able to pass in an alternate sync server
address via a command line flag and use that to develop their own sync
server. The initial UI doesn't include an option to configure an alternate
server. However, keep in mind that we wanted to get this in the hand of
users first and get some feedback about our overall sync quality. We will
iron out how to allow the configuration of a third party server a little
later on.
On Sat, Aug 1, 2009 at 3:47 AM, PhistucK <phist...@gmail.com> wrote:
> This is really, really cool.I was positive you will not implement this as
> a core feature, but expand the extensions system to support that instead
> (which kind of makes sense).
> Will there be an option to sync to a different server?
> Maybe others would like to create their own community cloud.
> ☆PhistucK
> On Sat, Aug 1, 2009 at 02:38, Tim Steele <t...@chromium.org> wrote:
>> On Fri, Jul 31, 2009 at 3:59 PM, Caleb Eggensperger <caleb...@gmail.com>wrote:
>>> The doc says:
>>> - Provide a web interface to access stored / synced bookmarks, likely
>>> via the docs.google.com doclist.
>>> What about google.com/bookmarks? Shouldn't be difficult -- toolbar syncs
>>> to there currently.
>> It's more difficult than you'd think. Chrome's different data model,
>> among other things, make it a lot like the "square peg in a round hole"
>> problem. But it's something we're looking into. For the first release,
>> we've just focused on getting sync to work between Chrome instances.
On Sat, Aug 1, 2009 at 6:04 PM, Idan Avraham <id...@chromium.org> wrote:
> [Resending from my @chromium.com address]
> When we fully land the sync code (hopefully in the coming few weeks),
> developers will certainly be able to pass in an alternate sync server
> address via a command line flag and use that to develop their own sync
> server. The initial UI doesn't include an option to configure an alternate
> server. However, keep in mind that we wanted to get this in the hand of
> users first and get some feedback about our overall sync quality. We will
> iron out how to allow the configuration of a third party server a little
> later on.
> On Sat, Aug 1, 2009 at 3:47 AM, PhistucK <phist...@gmail.com> wrote:
>> This is really, really cool.I was positive you will not implement this as
>> a core feature, but expand the extensions system to support that instead
>> (which kind of makes sense).
>> Will there be an option to sync to a different server?
>> Maybe others would like to create their own community cloud.
>> ☆PhistucK
>> On Sat, Aug 1, 2009 at 02:38, Tim Steele <t...@chromium.org> wrote:
>>> On Fri, Jul 31, 2009 at 3:59 PM, Caleb Eggensperger <caleb...@gmail.com>wrote:
>>>> The doc says:
>>>> - Provide a web interface to access stored / synced bookmarks,
>>>> likely via the docs.google.com doclist.
>>>> What about google.com/bookmarks? Shouldn't be difficult -- toolbar
>>>> syncs to there currently.
>>> It's more difficult than you'd think. Chrome's different data model,
>>> among other things, make it a lot like the "square peg in a round hole"
>>> problem. But it's something we're looking into. For the first release,
>>> we've just focused on getting sync to work between Chrome instances.
Looks great, Thank you, I wrote about this enhancement needed:
g) A bookmarks/applications/Chat floating tab WITHIN the browser,
Sharing ANY webpage with all my Contacts etc : Just like facebook
provides a useful toolbar at the bottom of browser page containing
list of applications/bookmarks/Contacts with whom one can chat, etc, a
browser floating tab is needed, which would be available at all web
pages that I visit. That way, I can share any webpage with all my
Contacts etc too. Or if one goes to www.playlist.com and logs in, you
will see a Meebo.com toolbar at bottom of screen, that shows ALL my
contacts from yahoo, msn, gmail, facebook, etc whom I can chat with
and share the webpage with. This toolbar should be available at all
web pages that I visit.
Besides others:
Chome Browser/Google Toolbar enhancements needed:
I love Chrome browser, some more enhancements will help:
a) Ability to create browser toolbar components, like "Search on
Wikipedia", "Stock symbol for Google Finance" for quick opening up of
websites, so I do not have to open up a new window and then type in my
specific search query.
b) Password Autofill and automatic login into a website: Avant Browser
(www.avantbrowser.com) has nice capability of creating password
autofills and logging into website for you. Google Chrome and other
browsers should also have this. Also there should be an option that
some passwords are stored only locally, and some can be stored on the
Internet (ie available from any computer, upon login).
c) I would like ability to annotate text on a webpage, kind of a
google notes, on webpages. For example, If a webpage has a list of
videos or lectures and I want to note down next to the videos which
ones I have watched so as to not watch them again, then I should be
able to annotate text notes on the webpage. Currently, I have to open
up separate google notes etc, which is cumbersome. Then, also I should
have ability to delete my notes (either some or all of them).
d) Bookmarklets (for quickly sending gmail, or quick post to Blogger,
or quick post to Facebook, note in Google Reader, etc) are critical
and should be key feature of any browser. Chrome and other browsers
should provide a big and growing list of bookmarklets, that users can
drag into their bookmarklets list. These are huge productivity gain.
Also it should provide capability for users to be able to create their
own bookmarklets for automating various things.
e) Bookmarklets directory : There should be a directory in google
chrome for bookmarklets (similar to directory of igoogle gadgets, that
users can pick from), since bookmarklets (for quickly sending gmail,
or quick post to Blogger, or quick post to Facebook, note in Google
Reader, etc) are critical.
f) Google Chrome auto-suggest not working for some sites: For example,
I want to start typing "rea..." and Google Chrome auto-suggest should
show my previously used "http://www.google.com/reader", ie Google
Reader. But typing "rea..." does not auto-suggest this site.
g) A bookmarks/applications/Chat floating tab WITHIN the browser,
Sharing ANY webpage with all my Contacts etc : Just like facebook
provides a useful toolbar at the bottom of browser page containing
list of applications/bookmarks/Contacts with whom one can chat, etc, a
browser floating tab is needed, which would be available at all web
pages that I visit. That way, I can share any webpage with all my
Contacts etc too. Or if one goes to www.playlist.com and logs in, you
will see a Meebo.com toolbar at bottom of screen, that shows ALL my
contacts from yahoo, msn, gmail, facebook, etc whom I can chat with
and share the webpage with. This toolbar should be available at all
web pages that I visit.
I agree on the convenience of syncing with the users' existing (if it
exists) Google Bookmarks data store. I myself have been using Google
Bookmarks for quite some time and built up a nice inventory that I
would love to sync directly to. Will this be a feature?
On Jul 31, 5:59 pm, Caleb Eggensperger <caleb...@gmail.com> wrote:
> - Provide a web interface to access stored / synced bookmarks, likely via
> the docs.google.com doclist.
> What about google.com/bookmarks? Shouldn't be difficult -- toolbar syncs to
> there currently.
> On Fri, Jul 31, 2009 at 14:07, 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 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!
On Jul 31, 5:07 pm, Tim Steele <t...@chromium.org> wrote:
> 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).
Fantastic idea. I love the notion of using XMPP for this. Now I just
hope that this doesn't go the way of Google Browser Sync. That was an
insanely useful service that got taken out back and shot, causing me
to relocate my sync'd bookmarks, etc. to Foxmarks, now Xmarks.
Along with this (ideally) should be a FF plugin, and possibly a SIMBL
plugin to use with Safari & the kids as well..
In theory, you can export your Google Bookmarks and import those into
Chrome. With this accomplished, you'd be in the "new system" which I
presume will ultimately replace Google Bookmarks, using the Google
Docs List as a replacement interface.
In the meantime, it will mean you won't be able to keep your Google
Toolbar (in Firefox and IE) bookmarks synced with Chrome until there
is an add-on for those browsers to sync with this new system.
On Aug 3, 11:07 am, "m.f" <michael.fa...@gmail.com> wrote:
> I agree on the convenience of syncing with the users' existing (if it
> exists) Google Bookmarks data store. I myself have been using Google
> Bookmarks for quite some time and built up a nice inventory that I
> would love to sync directly to. Will this be a feature?
> On Jul 31, 5:59 pm, Caleb Eggensperger <caleb...@gmail.com> wrote:
> > The doc says:
> > - Provide a web interface to access stored / synced bookmarks, likely via
> > the docs.google.com doclist.
> > What about google.com/bookmarks? Shouldn't be difficult -- toolbar syncs to
> > there currently.
> > On Fri, Jul 31, 2009 at 14:07, 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 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!
You don't even have to export from Google Bookmarks first and then import
into Chrome. The Chrome importer ("Wrench Menu" -> "Import bookmarks &
settings...") supports importing bookmarks from the Google Toolbar which is
the same set of Google Bookmarks associated with your @gmail address. This
is certainly not as nice as a two-way sync between the two stores, but our
focus is initially on syncing bookmarks between instances of Chrome.
On Tue, Aug 4, 2009 at 10:34 AM, Bob Oliver Bigellow XLII
<iam...@gmail.com>wrote:
> In theory, you can export your Google Bookmarks and import those into
> Chrome. With this accomplished, you'd be in the "new system" which I
> presume will ultimately replace Google Bookmarks, using the Google
> Docs List as a replacement interface.
> In the meantime, it will mean you won't be able to keep your Google
> Toolbar (in Firefox and IE) bookmarks synced with Chrome until there
> is an add-on for those browsers to sync with this new system.
> On Aug 3, 11:07 am, "m.f" <michael.fa...@gmail.com> wrote:
> > I agree on the convenience of syncing with the users' existing (if it
> > exists) Google Bookmarks data store. I myself have been using Google
> > Bookmarks for quite some time and built up a nice inventory that I
> > would love to sync directly to. Will this be a feature?
> > > - Provide a web interface to access stored / synced bookmarks,
> likely via
> > > the docs.google.com doclist.
> > > What about google.com/bookmarks? Shouldn't be difficult -- toolbar
> syncs to
> > > there currently.
> > > On Fri, Jul 31, 2009 at 14:07, 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!
People have plenty of bookmarks on IE using Google Toolbar. Will
these be synced with Chrome bookmarks as well? A lot of google users
were left out in the cold when switching from IE+GToolbar to Chrome,
as we had to leave our google bookmarks behind and start fresh (even
tho IE bookmarks could be imported into Chrome bookmarks from day
one!). Seems about time to show a little love to the google faithful,
and sync Chrome and IE Google Toolbar bookmarks right off the bat--
you could implement a similar method as Gmail's "merge contacts"
feature, allowing the user to eliminate duplicate entries himself.
just a suggestion.
10
On Jul 31, 5:07 pm, Tim Steele <t...@chromium.org> wrote:
> 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 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
People have plenty of bookmarks on IE using Google Toolbar. Will
these be synced with Chrome bookmarks as well? A lot of google users
were left out in the cold when switching from IE+GToolbar to Chrome,
as we had to leave our google bookmarks behind and start fresh (even
tho IE bookmarks could be imported into Chrome bookmarks from day
one!). Seems about time to show a little love to the google faithful,
and sync Chrome and IE Google Toolbar bookmarks right off the bat--
you could implement a similar method as Gmail's "merge contacts"
feature, allowing the user to eliminate duplicate entries himself.
just a suggestion.
10
On Jul 31, 5:07 pm, Tim Steele <t...@chromium.org> wrote:
> 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 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
> 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 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
> 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 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
If you happen to be using a Chromium (blue logo) build, then this is the
expected behavior. The feature is currently available as a preview via the
Google Chrome dev channel, but not in Chromium branded builds. Sync won't
be usable in Chromium until we can build the feature entirely from source.
To recap from Tim's email that started this thread:
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. . . . 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.
The glue code is out in the open already, and several of us are working on
getting the sync engine library to build as a fully open source part of
Chromium.
On Mon, Aug 17, 2009 at 10:12 PM, est <electronix...@gmail.com> wrote:
> not working on 4.0.202.0 (23600)?
> chrome.exe --enable-sync
> On Aug 1, 5: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 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!
|
