[webkit-dev] ResourceHandle and the Frame parameter
chrisb at adobe.com
Tue Jun 12 14:29:15 PDT 2007
It is important for the ResourceHandle in the apollo port to have
access to WebView state. We can live with a pointer to the Frame,
FrameLoader, Page, or any other object that allows us to walk back to
our WebView. We could add a factory method on FrameLoaderClient to
construct ResourceHandle's. ResourceHandle could become a pure
virtual interface, which would eliminate the need for the #if's in
the header and would allow clients to associate as much per frame
state with a ResourceHandle as they wanted.
Adobe Systems Inc.
On Jun 12, 2007, at 1:04 PM, Morgan L wrote:
> Congrats on the windows launch! :-)
> Now, on to my question...
> There is a comment in ResourceHandle.h about the Frame
> parameter to ResourceHandle's static create function.
> The comment suggests that the Frame parameter might be
> removed in the future or that it at least shouldn't be
> I wanted to make the case for keeping it (or something
> equivalent) there. In many cases, it is very useful
> to have context about what frame (document) is
> requesting a resource. This can be handy for simple
> things like logging, but it can also be useful for
> other things, like UI (e.g., security UI), that might
> be associated with a resource load. It may be the
> case that Safari can do without such context now or
> perhaps in the future, but for other consumers of
> webkit, it'd be great if this parameter could remain.
> If Frame is the wrong object (for some reason), then
> it could be some other object type so long as the
> Frame could be derived from it.
> Along these lines, I would also really like to add a
> Frame pointer to the ResourceHandle's
> loadResourceSynchronously method. This is important
> to my application and makes sense from the
> point-of-view of symmetry with ResourceHandle::create.
> Does this sound reasonable? If so, then I will
> prepare a patch and attach it to a bug.
> Got a little couch potato?
> Check out fun summer activities for kids.
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
More information about the webkit-dev