On May 6, 2009, at 11:40 AM, Jeremy Orlow wrote:
The way I see it, there's 2 uses for AppCache in the mobile space:
Simply speeding things up (i.e. just a cache) and web applications
you'd like to use offline. For the first use case, automatic
eviction (presumably via LRU) is quite acceptable. For the second
use case, I think you need some way to "pin" the app in the cache.
Anything that's pinned would not be subject to LRU. If the user
wanted to pin an app, but the memory was full of other pinned apps,
you could then present the user with an "uninstall" dialog.
I agree that the less UI the better, but I know I'd be mad if I
gmail offline stopped working simply because I hadn't visited the
site in a while.
I think it would be reasonable to assume that all uses of AppCache are
for use case #2, declaring an "application" that can potentially be
used offline. At least, I can't think of anyone eager to use AppCache
solely for performance. If it becomes such a widely used feature that
manual choice to remove an AppCache is not good enough for management,
then we could add a way for the app to draw a distinction.
I think adding a way to have some offline resources declared "pinned"
and others cleaned up in an LRU fashion in the implementation would be
ok, as it would allow making this choice through the UI, which seems
reasonable.
- Maciej
J
On Wed, May 6, 2009 at 11:37 AM, Jeremy Orlow <jor...@google.com>
wrote:
The way I see it, there's 2 uses for AppCache in the mobile space:
Simply speeding things up (i.e. just a cache) and web applications
you'd like to use offline. For the first use case, automatic
eviction (presumably via LRU) is quite acceptable. For the second
use case, I think you need some way to "pin" the app in the cache.
Anything that's pinned would not be subject to LRU. If the user
wanted to pin an app, but the memory was full of other pinned apps,
you could then present the user with an "uninstall" dialog.
I agree that the less UI the better, but I know I'd be mad if I
gmail offline stopped working simply because I hadn't visited the
site in a while.
J
On Wed, May 6, 2009 at 9:23 AM, Andrei Popescu <andr...@google.com>
wrote:
Hi,
I was recently looking at
https://bugs.webkit.org/show_bug.cgi?id=22700
I have a small patch that attempts to fix this issue by
1. allowing the ChromeClient implementers to decide what the size
limit should be,
2. evicting caches (in LRU order) from the database when the size
limit is reached and a new cache needs to be saved.
After an initial discussion with Alexey Proskuryakov on IRC, we agreed
to ask webkit-dev for advice on this matter: is LRU eviction the
correct thing to do? It seems clear that the intended usage of
Application Cache is to act as a repository for Web applications that
can be used offline. However, when the disk space allowed for this is
completely used up, would it be ok to make room for new apps by
automatically evicting existing ones? The advantage of this is that it
allows this feature to function without any UI at all. The drawback is
that some apps would suddenly stop working offline. The alternative is
to simply throw an error when the size limit is reached and expect the
UA to provide some UI that allows users to free space by
"uninstalling" existing apps. However, having another setting for this
may turn out to be inconvenient (it's hard to discover and increases
the burden on users who already have to deal with cookies, normal HTTP
cache, databases, geolocation, etc).
Many thanks,
Andrei
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
