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 <[email protected]> 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 <[email protected]> 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 [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
