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

Wed May 6 13:18:46 PDT 2009

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

> 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

Don't look at me.  I'm not the one who made the standard.  Unfortunately the
standard makes it virtually impossible for offline apps to span domains and
for you to cherry pick between multiple apps on one domain.  We might as
well embrace this fact and thus avoid creating yet another manifest.
 (Assuming others agree with our assumption that we do need some way to
pin applications.)

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

I think the presence of an AppCache manifest is enough.  An application
can't work offline without it.

> > 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/c96b1ad6/attachment.html>