--- Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
> 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.
In my case, I would prefer not to have to continually
modify ResourceHandleClient whenever I want to do
something that requires Frame level context. The
dialogs example was just an example (that
network-level dialogs may be undesirable in various
applications is not really relevant). I just want the
freedom to add things like this without having to
revise WebCore.
> > 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.
Again, the issue isn't performance. It is code
maintainability and the ability to develop rapidly.
Why would you guys want to support additional APIs on
ResourceHandleClient that you don't use? Wouldn't you
rather just support a Frame parameter (or some
equivalent)?
> > 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.
I think that many embedders also want control over the
way that resources are loaded into WebCore. I don't
think it is correct to restrict ResourceHandle. One
of the things that makes WebKit awesome for embedders
is how easy it is to layer stuff "above" and "below"
WebKit in the stack. I'd like to see that made even
easier :-)
> 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.
In general this is good, especially for things that
matter for
> Otherwise we have to totally rethink the intended
> separation of
> responsibilities between ResourceHandle and
> ResourceLoader.
I don't think much needs to change. This is just
about making WebCore more flexible.
Anyways, I hope you'll agree that making WebCore more
flexible is complementary to designing good, generally
useful callbacks.
--morgan
____________________________________________________________________________________
Get the free Yahoo! toolbar and rest assured with the added security of spyware
protection.
http://new.toolbar.yahoo.com/toolbar/features/norton/index.php
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
