On Wed, Oct 28, 2009 at 10:42 AM, Nick Carter <n...@chromium.org> wrote:
> On Wed, Oct 28, 2009 at 8:46 AM, Scott Violet <s...@chromium.org> wrote:
>>
>> I'm confused by the diagram. In step 5, why does F' get added to the
>> model. Are you saying the 'extension cloud' service always creates a
>> new bookmark, without verifying if the model already has a matching
>> entry?
>
> This is indeed the behavior we're seeing with one extension -- "delete all
> old bookmarks, write a whole new copy".
Ugh!
I don't think there is going to be a way to make it impossible to
write poorly written extensions. Perhaps sync should have a way to
detect lots of mutations from an extension and then disable either the
extension or itself at some point with a suitable warning. It should
certainly be possible to track number of mutations from an extension
and to know which extension is the result of the mutations.
-Scott
> - nick
>
>>
>> -Scott
>>
>> On Wed, Oct 21, 2009 at 5:08 PM, Tim Steele <t...@chromium.org> wrote:
>> > [re-sending from correct email account]
>> > Hi,
>> > I wrote up a document that discusses some interesting unintentional
>> > relationships that can exist between independent extensions, and how
>> > this
>> > general problem also currently affects the browser sync engine. This
>> > issue
>> > was discovered from trying to explain the primary symptom of unusually
>> > high
>> > syncing traffic generated by Chrome clients. Please find it here:
>> > A Tale of Two (or more) Sync Engines
>> > You should read that before continuing!
>> > This led to me thinking about what we do long term, short term, or
>> > basically
>> > before Chrome Sync and extensions are running in parallel in a beta
>> > channel
>> > environment. You'll see a bit of this at the end of the first document,
>> > but
>> > after posing the problem as an extensions problem I ended up at a random
>> > idea that I think makes at least a little sense, though I admit I was
>> > having
>> > fun thinking and writing about it so maybe I missed some major
>> > roadblocks
>> > along the way. There are downsides, mainly revolving around the added
>> > hand-holding we would impose on extensions. Please read! Hoping for
>> > comments and feedback. Extensions API "quotaserver"
>> > In addition to that, Colin and Todd (cc'ed) brought up some sync
>> > specific
>> > ideas they have (I mention it a bit at the end of the first doc). We'll
>> > try
>> > to get a separate thread going about this soon!
>> > Thanks!
>> > Tim
>> > >
>> >
>>
>> >>
>
>
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
