On Wed, Oct 28, 2009 at 10:42 AM, Nick Carter <[email protected]> wrote: > On Wed, Oct 28, 2009 at 8:46 AM, Scott Violet <[email protected]> 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".
One thing I forgot I wanted to point out about that extension in particular. In Tim's proposal he says: "...in Chrome Sync, we try really hard to not get into feedback loops with ourselves, and not to make unnecessary / no-op changes, but we have seen at least one extension (GBX) periodically delete all bookmarks and then recreate all bookmarks with no changes to the nodes in question. That seems almost positively unnecessary. If we detect that they have removed the same tree (from the same root position) 10 times in one day, this does really seem fishy and enough to trigger limiting. But at that point the onus is on extension developers, not us." It sounds like Tim agrees here, but I just want to reiterate: we should not be the arbiters of quality or taste wrt extensions. There will be buggy and crappy extensions. We should try and design things such that you have to go out of your way to write crappy things, but at the end of the day we want this to be an open environment where people surprise us -- both in good and bad ways :). If we need to protect our own systems that is fine, but other than that we shouldn't prevent things in the extensions system, even if they don't seem to make much sense. -a --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
