On Tue, Apr 7, 2009 at 11:27 AM, Maciej Stachowiak <mjs@apple.com> wrote:
On Apr 7, 2009, at 10:52 AM, Michael Nordman wrote:
I'm working on the app cache for Chrome. We've decided to hoist most the
functionality provided by the app cache into Chrome's main browser process, so we won't be using most of the implementation provided by WebKit. I'd like to work through what changes to make within WebKit/WebCore to allow an embedder pull that off. Any suggestions would be much appreciated.
One downside of this approach is that, if the application cache ever needs to change, it may be necessary to make changes to two separate implementations hosted in different repositories. In addition, quality-of-implementation improvements to one version won't benefit the other.
Please see my response to Darin earlier. There may be an opportunity to replace WebKit's impl of this feature with one that has more manageable dependencies. Perhaps chrome's implementation could be the basis for that replacement which could then be used within webkiit proper and within chrome's browser process. A first step along this path could be enabling somebody to wire in a different implementation that is lagging the current incarnation found in webkit at the moment and not ready for the prime time just yet. Some additional info about Chrome's as yet non-existent impl. It needs to be fairly independent of the core chrome codebase in order for it to be testable in our current testing infrastructure for the layout tests. This is a design constraint which will keep me honest regarding dependencies.
It's been a recurring theme for the Chrome team to request hooks to bypass WebKit functionality and replace it with Chrome-specific code that lives outside the WebKit tree. So far this has been mostly for code developed when Chrome was originally a secret project. While we felt it was best to grandfather in the existing carve-outs, in general I believe this is not the best way to move the WebKit project forward. I would not like to see this pattern replicated for newly developed functionality.
WebKit could grow a stronger sense of frontend vs backend that don't share an address space for features that require touching browser wide state. The current model for webkit doesn't lend itself well for that. We struggle with that a fair amount.
Regards, Maciej
In the code base right now, a single compilation flag enables or disables everything to do with app cache in WebKit, ENABLE(OFFLINE_APPLICATION). This turns on/off the scriptable interface bits as well as the backend implementation within webcore. I think I'd like a way to reuse the scriptable interface related bits provided by webkit, but to slide a chrome specific implementation under that interface. One thought was to separate this single flag into two flags, one for the scriptable interface bits and the other for the back end implementation.
ENABLE(APPLICATION_CACHE_INTERFACE) - surfaces the window.applicationCache property - pulls in the DOMApplicationCache.idl file - enables event targeting stuff for DOMApplicationCache - perhaps defines an abstract interface that a c++ class backing DOMApplicationCache scriptable API must implement
ENABLE(APPLICATION_CACHE_IMPLEMENTATION) // only valid if INTERFACE is also enabled - turns on the rest of the stuff in webkit for app cache, including a concrete implementation of that abstract interface mentioned above.
Does something along these lines make sense, or perhaps there is another way to approach this?
Thnx Michael
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev