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: > 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 --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
