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

Wed May 6 13:12:24 PDT 2009

On Wed, May 6, 2009 at 12:45 PM, Jeremy Orlow <jorlow at google.com> wrote:
> 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.

Assuming app == domain has proven problematic. Not only are there
multiple apps per domain, there are apps that span multiple domains.

> 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.

"sub-domains for each web application" has proven to be easier said than done

> 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.

Some thing the system needs is a 'trigger' to bring up such a UI. The
presence of a <html application='someurl'> attribute, in which the
descriptor file expresses it desire for the 'persistance' privilege,
could provide such a trigger.

> 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.
>
>