[webkit-dev] Blob scheme implementation
darin at chromium.org
Wed Sep 15 22:57:39 PDT 2010
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
> 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 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.
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
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.)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev