[webkit-dev] Blob scheme implementation

[Adam Barth]

What do you think of the idea of having a re-useable BlobCore module
that all the ports can share?

Adam


On Tue, Sep 14, 2010 at 5:39 PM, Jian Li <jianli at chromium.org> wrote:
> When I implemented the blob scheme handling, I intentionally tried to have
> some common implementation that could be used by all applicable platforms.
> But it seems that introducing BlobResourceHandle derived from ResourceHandle
> might not be a good hook up point because ResourceHandle is only a wrapper
> around the platform loading logics.
> To fix this problem, I can move all the blob handling logic to the platform
> specific layer (for WebKit mac) and it is up to other individual platform to
> implement it when needed.
> Jian
>
> On Tue, Sep 14, 2010 at 5:22 PM, Adam Barth <abarth at webkit.org> wrote:
>>
>> Jian Li just had a conversation in #webkit about where the code for
>> implementing the Blob URL scheme should live.  I thought I'd open the
>> discussion to webkit-dev in case folks had a different perspective.
>>
>> As part of the fileapi, we're introducing a new URL scheme, called
>> blob, which represents a bucket of bits, usually from a file, but
>> potentially from another location.  Assigning these objects URL is
>> helpful because then they integrate with the rest of the web platform.
>>  For example, you can use them as images via the <img> element or
>> videos via the <video> element, etc.
>>
>> Currently, the blob URL scheme is implemented with a subclass of
>> ResourceHandle (our primary network abstraction) called
>> BlobResourceHandle.  My sense is that this isn't the right place in
>> the architecture to add support for the blob URL scheme.  The issue is
>> that each port has a table somewhere that maps URL schemes to
>> networking backends.  In Chromium, for example, that mapping is
>> provided by URLRequestFactory, which lives in the "net" module.  By
>> implementing the blob URL scheme at the ResourceHandle layer, we're
>> short-circuiting that table.
>>
>> In some sense, this is analogous to adding an HTTPResourceHandle and
>> implementing the HTTP protocol inside of WebCore.  While its true that
>> most (all?) users of WebKit will need to wire WebCore up to an HTTP
>> library, that doesn't necessarily mean that WebCore should contain an
>> implementation of the HTTP protocol.  In the same way, even if a large
>> number of WebKit users will wish to support the blob URL scheme, that
>> doesn't necessarily mean that WebCore should contain an implementation
>> of the scheme.
>>
>> I can certainly see the appeal of sharing the blob URL implementation
>> code between different ports of WebKit, but we can achieve that goal
>> in a number of ways, including creating an external library or a
>> separate BlobCore module.
>>
>> Adam
>
>