[webkit-dev] Blob scheme implementation

[Adam Barth]

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