[Webkit-unassigned] [Bug 40627] Limit ApplicationCache Total and Per-Origin Storage Capacity (Quotas)

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Jun 23 11:43:07 PDT 2010


https://bugs.webkit.org/show_bug.cgi?id=40627


Joseph Pecoraro <joepeck at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #59545|                            |review?
               Flag|                            |




--- Comment #24 from Joseph Pecoraro <joepeck at webkit.org>  2010-06-23 11:43:06 PST ---
Created an attachment (id=59545)
 --> (https://bugs.webkit.org/attachment.cgi?id=59545)
[PATCH] Part 2 - Update Schema and enforce Per-Origin Quotas (needs part 1)

ChangeLog says it all. I made a decision here that could be debated:

In the Patch:
I ensure that `Origins` records only exist when there is a `Caches`
record that needs it. So, the lifetime of the quota is tied to whether
or not the origin has an application cache. If all caches on that
origin get deleted then the quota will be deleted as well.
  + There are never extra Origins records.
  - Requires an extra SELECT to count the number of Origin Records

Alternate Solution:
`Origins` records, and therefore quotas, should remain permanently,
or until the database is explicitly emptied. This way, once they are set
by the user for an origin, if the cache is deleted and later restored the
originally set quota would still be in effect.
  + Prevent reaching a low quota multiple times if caches come and go
  - May leave around stale Origins records.

Finally, I started taking the Databases Quota management approach, but
felt that was far to heavyweight. The approach I took just grabs the quota
and checks it again before committing to the new cache. The second
check may need to move into a SQL Transaction for storeNewestCache.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the webkit-unassigned mailing list