[webkit-dev] setting a size limit for Application Cache

Wed May 6 12:48:43 PDT 2009

Good point.  Tying the apps together is pretty important.  What good is it
for the program to still be in AppCache if it's data (in databases or
localStorage) was deleted by some other LRU policy?
I'm not sure that yet another manifest is needed though.  For databases and
localStorage, access is controlled via the origin.  It seems to me that the
minimum granularity for what gets pinned is thus the domain.

Yes, there can be multiple web applications per domain, but there's really
no way for WebKit to know which localStorage entries or which databases are
tied to each application.  Thus, eviction is an all or nothing thing for the
origin.  This is not such a horrible thing though; authors can always create
sub-domains for each web application.

So, in summary: I'm proposing that there be a UI to pin (or install, or
save, or whatever you want to call it) an origin + have a dialog for seeing
all the origins that are pined (for uninstall purposes).  All non-pinned
AppCache data would be removed in a LRU fashion.

J

On Wed, May 6, 2009 at 12:09 PM, Michael Nordman <michaeln at google.com>wrote:

> The chrome team had an interesting thread on this topic not long ago.
> Unfortunately it wasn't on the public chromium-dev mailing list, so I
> can't provide a link to it here :(
>
> <summary (according to me at least:)>
>
> The gist of it was that providing appcaching for general use w/o any
> special privileges is a good thing, but not all usages of this feature
> are qualitatively the same thing. In some cases it's purely about
> performance enhancement or reduced network utilization (traditional
> caching goals). In other cases it's about providing additional
> guarantees around application availability. Its fair to evict data
> cached for the former cases as needed, but not ok to evict data cached
> for the latter cases.
>
> There is no means for the system to distinguish between these two
> cases. There is no API to indicate which use is which.
>
> In the latter case (gauranteed app availability), there is more
> involved than the appcache... there are also databases, localstorage
> values to which the gaurantee extends to.
>
> What's missing is a way for "applications" to declare themselves as
> such and to establish privileges to keep data around forever. Given
> that, the system could relate persistent resource with "applications",
> and based on their privileges, evict or not when space becomes an
> issue.
>
> A handwavvy syntax for declaring an "application"... <html
> application='someurl'>... the url uniquely identifies the app, the
> resource loaded from that url contains a user friendly description and
> set of desired privileges... all pages that refer to that application
> url are considered part of that app... all resource created on behalf
> of that app are tracked by the system as such.
>
> Food for thought.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090506/e0e6de32/attachment.html>