On Sep 11, 2010, at 4:21 PM, Sam Weinig wrote: > It seems the dependency on Frame is now gone (as of last night I guess?) with > the advent of the NetworkingContext.
Neat. I was going to suggest using factory objects to create ResourceHandles (then they can stuff in whatever info they need, or add an external association or whatever), but I am not sure of the right scope for the factory. One per frame clearly, but Worker and SharedWorker would need separate handling. Perhaps they could piggyback off the factory of the initially creating frame. Regards, Maciej > > -Sam > > On Sat, Sep 11, 2010 at 3:42 PM, Maciej Stachowiak <m...@apple.com> wrote: > > On Sep 11, 2010, at 2:57 AM, Adam Barth wrote: > > > I don't mean to spam this list with design questions, but I'm trying > > to wrap my mind around how the loader is put together today and how > > we'd like it to be put together in the future. > > > > There's a FIXME in ResourceHandle that says that ResourceHandle > > shouldn't depend on Frame. (For those who aren't familiar with the > > loader, ResourceHandle is the primary platform abstraction WebCore > > uses to communicate with the network.) This makes sense to me for two > > reasons: > > > > 1) ResourceHandle is in WebCore/platform/network and therefore isn't > > allowed to depend on parts of WebCore outside the platform directory. > > 2) There are a number of types of network requests that are not > > associated with frames (e.g., XMLHttpRequests from WebWorkers, > > PingLoader, etc). > > > > Do we still believe this FIXME is accurate? If so, I have some time > > next week to look at removing the dependency. There's a patch that > > either recently landed or is about to land that furthers the use of > > Frame by ResourceHandle, so I wanted to check with folks more broadly > > about whether this is the right direction. (Note that I haven't > > studied the code yet, so I'm not sure what would be required to remove > > the dependency.) > > I think this is the right way to go. I don't clearly understand the reasons > this dependency was added, but I hope we can find an alternate design to meet > those needs. > > Regards, > Maciej > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
