Bug 54886

Summary: WebResourceCacheManager needs to manage the CFURLCache
Product: WebKit Reporter: Brian Weinstein <bweinstein>
Component: WebKit2Assignee: Brian Weinstein <bweinstein>
Status: RESOLVED FIXED    
Severity: Normal CC: ap, aroben, buildbot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: PC   
OS: OS X 10.5   
Attachments:
Description Flags
[PATCH] Fix
aroben: review+
[PATCH] Take 2 - Old Mac Project File
aroben: review+
[PATCH] Take 3 - Mac Project File + Feature Define aroben: review+

Description Brian Weinstein 2011-02-21 09:07:52 PST
WebResourceCacheManager needs to manage the CFURLCache

It currently only supposed the WebCore memory cache. It should also support the CFURLCache on platforms that use CFNetwork.
Comment 1 Brian Weinstein 2011-02-21 09:14:13 PST
Created attachment 83171 [details]
[PATCH] Fix
Comment 2 Adam Roben (:aroben) 2011-02-21 09:20:42 PST
Comment on attachment 83171 [details]
[PATCH] Fix

View in context: https://bugs.webkit.org/attachment.cgi?id=83171&action=review

I think you should share the Mac and Windows code by putting it in a new WebProcess/ResourceCache/cfnet/WebResourceCacheManagerCFNet.cpp and using a macro or an inline function to make it so you can use the same function names on both platforms. If you do that you should probably upload a new patch.

> Source/WebKit2/WebProcess/ResourceCache/WebResourceCacheManager.cpp:72
> +        CFStringRef host = (CFStringRef) CFArrayGetValueAtIndex(cfURLHosts.get(), i);

Please use a C++ cast.

> Source/WebKit2/WebProcess/ResourceCache/WebResourceCacheManager.cpp:73
> +        origins.add(SecurityOrigin::create("http", host, 0));

Should we store "http" in a String so we don't do the char*->String conversion on every iteration of the loop?

> Source/WebKit2/WebProcess/ResourceCache/WebResourceCacheManager.h:63
> +    CFArrayRef cfURLCacheHostNames() const;
> +    void clearCFURLCacheForHostNames(CFArrayRef) const;

The getter should return a RetainPtr. Maybe these should be static member functions?
Comment 3 Build Bot 2011-02-21 09:25:19 PST
Attachment 83171 [details] did not build on win:
Build output: http://queues.webkit.org/results/7942034
Comment 4 Brian Weinstein 2011-02-21 10:51:01 PST
Created attachment 83190 [details]
[PATCH] Take 2 - Old Mac Project File

The Mac project file hasn't been updated yet with the refactoring to WebResourceCacheManagerCFNet yet, but will be before landing.
Comment 5 Adam Roben (:aroben) 2011-02-21 10:53:45 PST
Comment on attachment 83190 [details]
[PATCH] Take 2 - Old Mac Project File

Brian said he's going to update WebKit2.xcodeproj soon, once he can use his Mac again. And that he'll update WKSI before checking in.
Comment 6 Build Bot 2011-02-21 11:15:22 PST
Attachment 83190 [details] did not build on win:
Build output: http://queues.webkit.org/results/7938892
Comment 7 Brian Weinstein 2011-02-21 12:47:56 PST
Created attachment 83205 [details]
[PATCH] Take 3 - Mac Project File + Feature Define
Comment 8 Build Bot 2011-02-21 13:54:17 PST
Attachment 83205 [details] did not build on win:
Build output: http://queues.webkit.org/results/7939861
Comment 9 Brian Weinstein 2011-02-21 14:28:41 PST
Landed in r79252.
Comment 10 Alexey Proskuryakov 2011-02-22 14:24:23 PST
WebKitSystemInterface.h capitalizes names differently for the very reason of preventing directly using them. Please have a look at how all other WK exports work - you need to add them WebCore/WebCoreSystemInterface, and then to both WebKit1 and WebKit2 WebSystemInterface.

Please fix it soon.
Comment 11 Alexey Proskuryakov 2011-02-22 14:32:36 PST
Brian explained that this WKSI use is not in WebCore, so what I said made no sense.
Comment 12 Alexey Proskuryakov 2011-02-22 15:45:18 PST
It's still strange that this is the only WKSI function that we ever used in cross-platform code in WebKit. Could this mean that this code should really be moved to WebCore? WebKit should ideally be nothing but a thin wrapper around WebCore.