[webkit-dev] Blob scheme implementation

[Michael Nordman]

On Wed, Sep 15, 2010 at 9:15 AM, Darin Fisher <darin at chromium.org> 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.
>
>
>
>>
>> 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.
>

+1 "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."

AppCache loading has been mentioned a couple times in this thread. Really,
the points of integration between the loader and the appcache are mostly
smoke and mirrors in chrome... loading out of an appcache actually happens
via ResourceHandle in our port. Webcore's webarchive loading wouldn't work
in a sandboxed renderer either.

I'm working up to a similar 'where to put what code' conundrum around
xhr.responseBlob. Ideally, I'd like ResourceHandle to produce the blob.

ResourceHandle vs PlatformResourceHandle, maybe a class like the latter
could have a 'capabilities' interface that allowed common code to query
things like 'CanProvideResponseBlobs' and if not provides that capability in
common code. Similarly a 'CanHandleBlobScheme' capability query could
provide a fork in the road for loading blob urls (so the common code impl
would poke at the BlobRegistry singleton).

Subclassing ResourceHandle for blob url loading is probably not the most
elegant thing, but given the current state of the code base,  it's not a bad
option.

This schism around ResourceHandle in particular is a recurring theme. The
recurring answer "do it in the loader" just doesn't work so well for us.


>
> -Darin
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100915/ffb60622/attachment.html>