[webkit-dev] ResourceHandle and the Frame parameter

[Maciej Stachowiak]

On Jun 12, 2007, at 5:41 PM, Morgan L wrote:

>
> --- Maciej Stachowiak <mjs at apple.com> wrote:
>
>>
>> On Jun 12, 2007, at 5:22 PM, Maciej Stachowiak
>> wrote:
>>
>>>
>>> On Jun 12, 2007, at 2:33 PM, Darin Adler wrote:
>>>
>>>> I think we'll have to rethink this.
>> ResourceHandle is intended to
>>>> be a low level networking layer, and so it
>> doesn't make sense to
>>>> have higher level concepts like a Frame*, but
>> clearly we'll need
>>>> to make a design change so there's a higher level
>> that's easy to
>>>> plug in to.
>>>>
>>>> Or we can just give up on the notion of
>> ResourceHandle as a low
>>>> level networking abstraction.
>>>
>>> As Darin says, the intent is that ResourceLoader
>> is the layer that
>>> knows about high-level networking stuff in the
>> engine,
>>> ResourceHandle is supposed to be low-level and
>> ignorant of the
>>> higher-level loading code. In my opinion, the
>> right way to put in
>>> hooks that depend on the loading context would be
>> to add
>>> appropriate ResourceHandleClient methods.
>>
>> Now that I think about it, I guess that won't do
>> much to help you add
>> port-specific hooks - although the
>> ResourceHandleClient (normally a
>> ResourceLoader) could call up to a platform-specific
>> WebKit layer via
>> FrameLoaderClient. It's hard to tell what the best
>> model is without
>> more details about why the low-level networking code
>> in question
>> needs access to the high-level objects.
>
> I tried to give some motivating examples in my initial
> post.  A good example is network code that might like
> to put up a dialog, and it would like that dialog to
> be properly parented above the window from which the
> resource request originated.

Our approach for this in WebKit would be to make it a delegate  
callback up to the app - we never throw up dialogs from low-level  
code without control over the app. I think other ports should have  
the same approach, unless there's some deep reason that can't be done.

> There could also be
> network policy decisions, which do not involve UI,
> that depend on the originating frame.

Policy decisions are something that we try to do at the  
ResourceLoader layer or calling up to WebKit or all the way to the app.

> In both cases, it may be more costly to implement solutions using  
> callbacks to the ResourceHandleClient.

Is it really that big a deal? We already have a bunch of stuff on Mac  
and Windows Safari that calls all the way up to the app (for instance  
on every redirect) and it is not a significant performance hit.

> In short, forcing consumers / embedders to plumb new
> hooks through ResourceHandleClient and ResourceLoader
> seems like a larger burden, both in terms of initial
> development and maintainability (since the hooks
> wouldn't be exercised by Safari).

The tradeoff is that it breaks the intended layering of WebKit.  
WebCore/platform should be a layer that wraps platform-specific APIs.  
It should (in theory) have no knowledge of higher-level parts of  
WebCore, and should communicate solely through abstract client  
interfaces. WebKit should be the layer that implements API and policy  
"on top" of the core networking code.

It may be that this approach is ultimately not workable, but I'm not  
really convinced by your examples. There's no reason new dialogs or  
policy decisions can't be handled the same way that all the existing  
ones are, as far as I can tell.

> At any rate, my hope is that you will accept a trivial
> patch to plumb a Frame down to
> ResourceHandle::loadResourceSynchronously and that you
> will preserve some context that is equivalent to the
> Frame in the future.  I think "less is more" in this
> case :-)

I really think that moves things in the wrong direction. I'd rather  
see patches to add appropriate ResourceHandleClient calls to handle  
the cases of interest to you.

Otherwise we have to totally rethink the intended separation of  
responsibilities between ResourceHandle and ResourceLoader.

Regards,
Maciej