On Tue, Oct 27, 2009 at 8:55 PM, Tim Steele <[email protected]> wrote:
> I can take a stab at more formal heuristics for bookmarks, at least. We
> will have a better idea of actual limiting parameters for bookmarks (as in
> how many operations in a certain time frame is reasonable) once the
> ExtensionsActivityMonitor I just landed percolates and we can aggregate
> across representative sample data it produces.
A couple thoughts:
a) I think it is overly clever to hash the changes to the bookmarks
and count per unique-params. This can be easily or accidentally
defeated by just doing something like update({title:"foo"}),
update({url:"blech"}), over and over, anyway. Instead, at least for
bookmarks, I think a simple per-item-count is very reasonable. It
doesn't make sense to me to update the same bookmark more than a few
times per minute. An easy heuristic could be that updating the same
bookmark more than twice a minute sustained over 10 minutes. For
creates it's a bit tricker. In that case, maybe the best we can do is
the same combination of properties.
b) What is wrong with solving this by rate limiting the communication
between the Chrome sync client and the Chrome sync server? It seems
like that would be more foolproof; if the client tries to send too
many updates for any reason, they are rate limited.
- a
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: [email protected]
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
