[webkit-dev] Blob scheme implementation

[Maciej Stachowiak]

On Sep 15, 2010, at 1:06 PM, Darin Fisher wrote:

> On Wed, Sep 15, 2010 at 12:56 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> 
> On Sep 15, 2010, at 9:15 AM, Darin Fisher wrote:
> 
>> On Wed, Sep 15, 2010 at 8:58 AM, Alexey Proskuryakov <ap at 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).
> 
> That means that app cache doesn't work for HTML5 media in !Chromium.  It also means that blob URLs won't work for HTML5 media in !Chromium.

Both these things are likely to be true anyway, since most media back ends do not even use ResourceHandle. We have a design to fix both of these things for the Mac port, and it would not suffer from these features being at the ResourceLoader layer.

>  
> 
>> 
>>  
>> 
>> 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.
> 
> 
> I don't see any other examples of URL schemes being handled at the ResourceLoader level.

Indeed, there aren't any. Most URL schemes do not depend on higher-level features of the Web platform. The "blob:" scheme is not quite as magical as "javascript:", but it is more magical than "http:".

> 
> I'm not thrilled to introduce more ways in which Chromium and !Chromium differ, but integrating blob URLs at the ResourceLoader is not an option for Chromium.

Chromium has made some different design choices. Often, following these to their logical conclusion leads to designs that look like layering violations from the pure WebKit perspective. I sympathize with the need to have a design that's viable in the face of a process split. We are certainly learning a lot about this as we integrate multiprocess functionality into WebKit itself. However, as we do more of this work, I become more skeptical that doing multiprocess actually requires quite so many layering violations, and so I am hesitant to bend the architecture of WebKit around the desire to do things that way.

In fairness, we currently have networking running in the Web process, and so have not faced down all of the issues related to I/O living in a separate process. However, I am pretty confident that the file I/O needs for Blobs can be handled without messing with the ResourceHandle layer, in a way that is compatible with sandboxing.

Maybe at some point, a few of us should get together in person to talk about the right WebCore-level architecture to support multi-process ports while continuing to support a single-process design and with good abstractions and layering.

Regards,
Maciej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100915/41a1078f/attachment.html>