Have not read all of it yet, but am in favor in general of having some
sort of quota for extension api calls to protect from meltdown.
We have a very convenient chokepoint to implement this in our system,
so it would just be a matter of a more detailed design of the
heuristics to use for each API type.
- a
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
-~----------~----~----~----~------~----~------~--~---
