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

[Maciej Stachowiak]

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 <jorlow at 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 <andreip at 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 at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090506/341dd496/attachment.html>