Now, will there soon be a way to add a reference item in Google Docs at the Google Chrome section there?I mean, when you go to Google Docs, after you sync, there is a "Google Chrome" folder under "My Folders". When you go into it, there are folders and the items has some sort of a reference icon. Will it be made possible to add references not through the browser? (If so, any time frame?)
Thank you, this is a cool feature. ☆PhistucK On Tue, Aug 18, 2009 at 09:13, Nick Carter <n...@chromium.org> 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 <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 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 -~----------~----~----~----~------~----~------~--~---
