On Sep 15, 2010, at 9:15 AM, Darin Fisher wrote:

> On Wed, Sep 15, 2010 at 8:58 AM, Alexey Proskuryakov <a...@webkit.org> wrote:
> 
> 14.09.2010, в 22:15, Darin Fisher написал(а):
> 
> > I think it makes sense to extend ResourceHandle.cpp to access the 
> > BlobRegistry singleton in order to support blob URLs.
> 
> 
> The problem I see with adding blob support to ResourceHandle is that it makes 
> it too difficult to maintain. It used to be a platform abstraction, and it 
> was hard enough to make sure it worked well across platforms. Adding a 
> significant amount of cross-platform logic on top of that isn't going to make 
> it easier - especially when it's done via subclassing.
> 
> I don't understand why this seems so complicated.  ResourceHandle.cpp 
> contains some code that is shared by all WebKit ports that can access their 
> network stack directly from the WebKit main thread.  It already has some 
> common code for handling certain error cases (invalid URL, bad port).  This 
> is the best point in the code to integrate blob URL support.
> 
> Maybe subclassing ResourceHandle is not the best way to go about this.  It 
> seems fairly clean to me, but then, I'm not sure what the alternative 
> proposals look like.

I posted a proposal yesterday (do it at the ResourceLoader layer, since that's 
how the app cache hooks in).

> 
>  
> 
> An example that prompted me to look into this was 
> <http://trac.webkit.org/changeset/67503>. Here, a static function that 
> reported platform capabilities had to become virtual, so that it could take 
> blob loading logic into account. There is nothing in common between "are we 
> running on a version of Mac OS X that supports this" and "are we loading a 
> blob", and remembering this twist won't be easy.
> 
> Perhaps the static function should remain but be renamed?  That way it can 
> remain the function that reports platform capabilities.  However, as this 
> patch demonstrates, from WebCore's point of view, this needs to be a property 
> of ResourceHandle.
> 
> Maybe it would help if we better formalized the abstraction to the network 
> stack and let ResourceHandle grow to be a smart (contains cross-platform 
> helper code) front-end to that.

I think that's not the right design. ResourceHandle is supposed to be a thin 
abstraction on top of the network library. ResourceLoader is supposed to be the 
"smart" layer.

Regards,
Maciej


_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Reply via email to