[Webkit-unassigned] [Bug 25436] Refactor appCache for use in multi-process browsers

[bugzilla-daemon at webkit.org]

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





------- Comment #4 from michaeln at google.com  2009-05-01 12:50 PDT -------
 > Having a separate thread for appcache doesn't feel natural to me. It's just
a
> part of the loader, why should it have a life of its own?

The point of this refactoring is to be able to reuse the same core appcache
code out of process. When these classes are used out of process, they will be
running on a seperate thread. So I'd like to have the single process impl be
similarly arranged.

The intricate dependencies between the 'loader' and the appcache make reuse
very impractical. A big part of this proposal involves moving those points of
integration (for resource loading) closer to ResourceHandle (inside of the
ResourceHandle really since the cache hit detection and retrieval will actually
occur on the far side of the ipc wire in chrome). 

> The patch does not include any examples of how the new interfaces will be used
> in loader. It is not clear if there are many calls that can be made
> asynchronous. E.g., ResourceLoader::load() needs to look up appcache resources
> synchronously before creating a ResourceHandle, and
> ResourceLoader::willSendRequest() needs to do the same before returning.

Right, how to use the ApplicationCacheInterceptor interface in webkit
(single-process) is the crux of this (for the single-process impl). Looking for
some webkit expertise to provide some insight. My best guess is something like

Introduce a new ResourceHandle class that wraps the existing ResourceHandle
class (call the latter ResourceHandleRaw or something?). Have the new wrapper
use the interceptor interfaces and perhaps never create the 'raw' handle or
drop the raw handle in the fallback case.

Note that this work would NOT be required in order to use these classes in
Chrome.


> I don't know how resource loading is implemented in Chromium sufficiently well
> to comment.

Chrome is actually pretty well setup to employ this flavor of
ApplicationCacheInterceptor interface. See http://codereview.chromium.org/79036
for for how this fits in there.

> Maybe it would make sense to discuss this on the mailing list in
> order to determine whether this should be a model for other projects
> potentially using WebKit in multi-process configuration.

What jeremy said ;)


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.