[Chromium] Move the next traunch of headers into public/platform

• Component: New Bugs
• Status: RESOLVED FIXED

[Adam Barth]

[Chromium] Move the next traunch of headers into public/platform

[Adam Barth]

Created attachment 116488 [details]
Patch

[WebKit Review Bot]

Please wait for approval from [e-mail] before submitting because this patch contains changes to the Chromium public API.

[Darin Fisher (:fishd, Google)]

Comment on attachment 116488 [details]
Patch

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

> Source/WebKit/chromium/public/WebGraphicsContext3D.h:-129
> -    virtual bool initialize(Attributes, WebView*, bool renderDirectlyToWebView) = 0;

we're going to want to unwind this dependency on WebView at some point.

> Source/WebKit/chromium/public/platform/WebKitPlatformSupport.h:53
> +class WebApplicationCacheHost; // FIXME: Does this belong in platform?

the storage systems are interesting.  one approach is to say yes, but we need to ensure that policy decisions are handled at the Web{Frame,View}Client level instead.  this is what you would do if it was about access to the filesystem or network stack, so why not other subsystems like the appcache or indexed db backend?

[Adam Barth]

> we're going to want to unwind this dependency on WebView at some point.

I've added a FIXME.

> > Source/WebKit/chromium/public/platform/WebKitPlatformSupport.h:53
> > +class WebApplicationCacheHost; // FIXME: Does this belong in platform?
> 
> the storage systems are interesting.  one approach is to say yes, but we need to ensure that policy decisions are handled at the Web{Frame,View}Client level instead.  this is what you would do if it was about access to the filesystem or network stack, so why not other subsystems like the appcache or indexed db backend?

Makes sense.  I'll need to study these classes more to see how close we are to make that work.

[Adam Barth]

Committed r101224: <http://trac.webkit.org/changeset/101224>