On Wed, May 6, 2009 at 12:45 PM, Jeremy Orlow <[email protected]> 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 <[email protected]> > 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. > > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
