[webkit-dev] Blob scheme implementation

David Levin levin at chromium.org
Tue Sep 14 17:56:49 PDT 2010

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

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.


> 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
> >
> >
> _______________________________________________
> 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/1f5120aa/attachment.html>

More information about the webkit-dev mailing list