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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev