[webkit-dev] ResourceHandle and the Frame parameter

[Morgan L]

--- 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.  There could also be
network policy decisions, which do not involve UI,
that depend on the originating frame.  In both cases,
it may be more costly to implement solutions using
callbacks to the ResourceHandleClient.

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).

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 :-)

--morgan


      ____________________________________________________________________________________
Shape Yahoo! in your own image.  Join our Network Research Panel today!   http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7