[webkit-dev] Blob scheme implementation

[Darin Fisher]

On Wed, Sep 15, 2010 at 3:31 PM, Maciej Stachowiak <mjs at apple.com> wrote:

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

I do think it would be good to have a more in-depth face-to-face discussion
about this topic.

My argument boils down to the following:

1)  It is valuable for downloads to go directly from network stack to file
system without having to route through the sandboxed child process and back
up to the non-sandboxed parent process.

2)  It is valuable to have all protocols handled in one central place
(excluding javascript: because it is so weird).

3)  It is valuable for blob: URLs (and appcache) to work with HTML5 media.

4)  Where do you draw the line?  If blob: should not be handled by
ResourceHandle, then what about data:, about:, or even file:?  Why is it the
case that those things which have nothing to do with HTTP are also
implemented by ResourceHandle?

I think once you start pulling on this thread, the design choices made for
Chromium will begin to make sense.  (Ditto for the way we have implemented
appcache for Chromium.)

Regards,
-Darin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100915/35ee67a4/attachment.html>