On Jun 12, 2007, at 5:41 PM, Morgan L wrote:
--- Maciej Stachowiak <[EMAIL PROTECTED]> 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
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
