Re: [chromium-dev] reset bookmark sync?

[Idan Avraham]

Hello Rakka,

The chromium-dev mailing list is meant for development related discussions
and not for reporting issues such as the one you describe.

Can you please open a bug through http://www.crbug.com and provide detailed
info about the repro steps and the symptoms? Also, include the output from
about:sync in the bug's description. We can continue the discussion in the
bug (feel free to email the bug number directly to me once you open it).

On Tue, Nov 24, 2009 at 8:15 AM, Rakka Rage  wrote:

> is there a way to reset bookmark sync? i had it working initially but
> after playing around with it for a while it stopped working...
>
> thanks
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>http://groups.google.com/group/chromium-dev
>



-- 
-Idan

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

[chromium-dev] Sync engine code landing in trunk later today

[Idan Avraham]

Hi all,

This is just a heads-up that we are going to land the sync code in trunk
later today. After committing the sync glue code a little over a month ago,
we are now ready to commit the code we use for building syncapi.dll, which
is the sync DLL we included in the recent Dev Channel releases. We will
first commit the code with no changes to the gyp files (so initially the
code won't be built by default) and shortly after that we'll make the gyp
changes that will allow building syncapi.dll. We are doing this in two
separate commits so that we don't have to revert all the sync files if we
run into build issues related to the gyp changes.

I'll reply to this email when we are done and explain what needs to be done
to build syncapi.dll.

Please let me know if you have any questions or concerns.

BTW - our plan is to get rid of syncapi.dll in the near future and switch to
linking the sync code as a static library.

-- 
-Idan

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: Chrome Sync question

[Idan Avraham]

Hi Robert,

Yes, we are preparing to start letting users test Chrome Bookmark Sync
really soon. We landed a portion of the code in trunk yesterday (behind an
#ifdef), but there is no Chromium ToT build as of yet. Please stay tuned as
this feature will go to the Dev Channel once it is ready for public
consumption.
You can find more details about our plan here:
http://groups.google.com/group/chromium-dev/browse_thread/thread/bdacc1bdf3c5cb6a

On Wed, Aug 5, 2009 at 8:52 AM, Robert Dailey  wrote:

>
> Hello,
>
> I've recently read news about a new feature going into Chromium that
> allows bookmarks to be synchronized online. Is this feature currently
> available in a CI build of Chromium? If not, are there any
> speculations as to when this feature will be ready for testing/usage?
>
> Thanks!
> >
>


-- 
-Idan

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: browser/sync is moving in

[Idan Avraham]

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
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"  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  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  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 
> 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 func

[chromium-dev] Re: browser/sync is moving in

[Idan Avraham]

[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  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  wrote:
>
>>
>>
>> On Fri, Jul 31, 2009 at 3:59 PM, Caleb Eggensperger 
>> 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.
>>
>>
>>
>
> >
>


-- 
-Idan

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

[chromium-dev] Re: browser/sync is moving in

[Idan Avraham]

[Resending from my @chromium.com address]

Peter,

Many thanks for the feedback.

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  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  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  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 com