[Webkit-unassigned] [Bug 30322] WebKit level persistent caching

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=30322

Sergio Villar Senin <svillar at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |svillar at igalia.com

--- Comment #32 from Sergio Villar Senin <svillar at igalia.com> ---
These are my comments based from my experience implementing the libsoup's HTTP cache, I guess this is an initial implementation that will be iterated so feel free to ignore most of my comments:

* having 1 file per resource is a source of disk fragmentation, many resources are smaller than disk block size so the cache ends up being bigger than expected (at least this is an issue we have in libsoup)
* missing entry eviction based of cache size. That will likely require some other missing pieces, like an LRU for evicting old resources, code to make room for new resources should the cache be full...
* key filter is built by transversing the directory, are you planning to have some kind of index file (perhaps with precomputed data) instead of doing that? (the index file brings many other issues BTW specially related to consistency after crashes and so).
* shouldn't we have some extra check to avoid issues with clashes in the key filter? (in chromium they have [key,linkedlist] pairs to avoid this IIRC)

If I understood this correctly this is a first (very nice!) step, so I guess the most important thing is to have a good API for the cache. Later on, it could be evolved to improve its efficiency like having block-files storage for small resources alà Firefox), mmap'ed writable indexes to reduce the size of the key hashes in memory, etc...

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20141110/82df831f/attachment-0002.html>