[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 #7 from michaeln at google.com  2009-05-04 12:30 PDT -------
> Having a separate thread for appcache doesn't feel natural to me.
>
> It is true that some appcache operations are rather time consuming, and it may
> be nice to move them to a secondary thread. Two distinct examples are loading
> from disk database and prefix lookup for fallback.

The requirement (in my proposal) that the backend thread doesn't do blocking IO
(or anything that makes this thread unresponsive for an extended period) seems
somewhat unnatural, its a background thread so why not let it block. But
considering that this thread will be servicing requests for all pages, I think
it does make sense.

New topic... tactics...

Assuming we'll proceed with a refactor involving a front/back split (details of
that split aside for a moment), what's a good way to have the refactored impl
co-exist with the existing impl until we're ready to make a switch. (I think
its safe to say that this will take more than a single patch to pull off).
Would this be acceptable?

1. Define a new ENABLE(APPLICATION_CACHE) flag for this feature distinct from
ENABLE(OFFLINE_WEB_APPLICATIONS) flag. Make them be mutually exclusive. 
Perhaps call it EXPERIMENTAL_APPLICATION_CACHE until enough is in place to be
functional.

2. Submit the front-end classes that don't do anything yet.
2a. Land the WebApplicationCache and WebApplicationCacheContext base classes.
And have the default factory method return a NOOP implementation.
2b. Rework DOMApplicationCache (and related points of integration to support
event targeting and the window.applicationCache property) to call the new
front-end, to respect the new ENABLE flag.

3. Start work on the back-end


-- 
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.