[webkit-dev] Blob scheme implementation

[Darin Fisher]

I think it makes sense to extend ResourceHandle.cpp to access the
BlobRegistry singleton in order to support blob URLs.  This will work for
all ports that use ResourceHandle.cpp (everyone except Chromium AFAIK).  I
don't think we need to overabstract this.

When designing this system, we took a hard look at how we could make
Chromium reuse a WebCore implementation of  BlobRegistry and
BlobResourceHandle, but it just isn't a good match for Chromium's network
stack.  We need to subclass URLRequestJob (defined in Chromium's network
stack), and it would just be a big mess to convert between WebCore types and
Chromium types.  The amount of code that could be shared would be so small
that it just didn't seem worth it.

-Darin

On Tue, Sep 14, 2010 at 9:58 PM, Jian Li <jianli at chromium.org> wrote:

> Indeed when I implement BlobResourceHandle, I have taken the range request
> support into consideration and got it work. The problem is that current
> media element implementation does not route through ResourceHandle.
>
> However, introducing a ResourceHandle subclass does not sound like an
> elegant solution given that ResoucreHandle is currently treated as a wrapper
> class to the underlying platform implementation. I agree it would be better
> if we could find a way to avoid extra roundtrip to pop back to WebCore to do
> the real handling. But I am not sure how this could be hooked up. The
> handling of javascript: url is somewhat special. Probably we cannot do the
> similar thing as it since the handling of blob: url needs to work closely
> with resource loader and caching layer so that we can get it work in all
> scenarios.
>
> Do you have any good suggestion on what is the right layer to hook into?
> Does it make sense if I move the current implementation of
> BlobResourceHandle to the underlying platform layer for WebKit mac so that I
> can fix the issue with incorrect subclassing of ResourceHandle?
>
> On Tue, Sep 14, 2010 at 6:21 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
>>
>> On Sep 14, 2010, at 6:02 PM, Adam Barth wrote:
>>
>> > On Tue, Sep 14, 2010 at 5:56 PM, David Levin <levin at chromium.org>
>> wrote:
>> >> On Tue, Sep 14, 2010 at 5:42 PM, Adam Barth <abarth at webkit.org> wrote:
>> >>> What do you think of the idea of having a re-useable BlobCore module
>> >>> that all the ports can share?
>> >>
>> >> I don't think this is a good idea. This "re-usable module" would only
>> be
>> >> used by the Safari WebKit port. As I understand it, Chromium wouldn't
>> be
>> >> able to re-use it due to not re-using WebKit types in general. With
>> only one
>> >> port using it, the module seems like it would not be able to have a
>> good
>> >> design.
>> >>
>> >> So if there is a change, it seems better to just write it for the
>> Safari
>> >> WebKit port and as other ports want to implement it, if they find
>> >> commonality, it would be in their best interest to refractor the
>> existing
>> >> code for better re-use.
>> >
>> > Would Chromium be able to re-use the code if it were part of WebCore?
>> > I guess I don't understand what's different about those two cases.
>> >
>> > Another question, does this design allow blob URLs to be used by the
>> > <video> element?  My understanding is that <video> bypasses
>> > ResourceHandle because ResourceHandle isn't smart enough to handle
>> > range requests (or something like that).
>>
>> At least on Mac, the media elements miss out on a number of networking
>> features due to not going through the CachedResource layer and those below.
>> For example they don't work with the app cache. It's something we'd like to
>> fix eventually.
>>
>> Note: ResourceHandle would probably work and can handle range requests
>> fine, but the media APIs on Mac make it tricky to fully replace the loading
>> that the media framework likes to do for itself. If we had that, we could
>> hook up ResourceHandle pretty easily. The cache layer would need to be
>> enhanced to handle ranges though.
>>
>> Regards,
>> Maciej
>>
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>
> _______________________________________________
> 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/20100914/99b1af25/attachment.html>