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