Official explanation - http://blog.chromium.org/2008/10/google-chrome-chromium-and-google.html
☆PhistucK On Tue, Aug 18, 2009 at 09:19, est <[email protected]> wrote: > > Thanks for the explaination, Nick Carter. > > I understand now, Chrome is a Google product while Chromium is a open- > source project. > > Any thing else differs between Google Chrome and Chromium? I found > dictionaries missing from Chromium. > > On Aug 18, 2:13 pm, Nick Carter <[email protected]> wrote: > > Hi est, > > > > 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. > > > > - nick > > > > > > > > On Mon, Aug 17, 2009 at 10:12 PM, est <[email protected]> wrote: > > > > > not working on 4.0.202.0 (23600)? > > > > > chrome.exe --enable-sync > > > > > On Aug 1, 5:07 am, Tim Steele <[email protected]> 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: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
