[webkit-dev] Blob scheme implementation

[Jian Li]

I think it is a good idea but it will involve lots of work to figure out how
to build and test such module that could be used by all the ports. My
concern is that I do not have enough resource to speak of for all other
ports. Thanks.


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?
>
> 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
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100914/31308841/attachment.html>