[webkit-dev] Blob scheme implementation

[Darin Fisher]

On Tue, Sep 14, 2010 at 5:52 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Sep 14, 2010, at 5:22 PM, Adam Barth wrote:
>
> >
> > 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.
>
> I'm not sure about this. The reason WebKit defers to a port-specific
> library for networking originally stemmed from the desire to integrate with
> existing libraries that might have non-Web clients. While this has some
> benefits, it also has some costs - many aspects of the HTTP stack have
> compatibility impact and so WebKit-based browsers vary more in their
> Web-facing behavior than they would otherwise.
>
> In the case of the blob: scheme, my understanding is that it makes no sense
> outside the browser context, and has tight interactions with other parts of
> the platform - for instance, my understanding is that blob: URLs are not
> permanent but rather may cease to be valid as some point (correct me if I'm
> wrong).
>
> This makes me think that blob: URLs are maybe more like javascript: URLs,
> in that trying to make them part of the network library would actually
> produce layering violations rather than resolving them, and would not in
> practice benefit non-browser clients of those libraries. Threading
> javascript: URLs through the network stack only to pop back to WebCore to do
> the actual processing would be silly. I think maybe blob: is the same way,
> though to a lesser degree.
>
> Regard,
> Maciej
>
>
The key issue, which I think has been touched on elsewhere in this thread,
is HTML5 media.  Since that doesn't use ResourceHandle, it is necessary for
blob URLs to be integrated at a lower level so that the HTML5 media engine
can access them.

There is also another Chromium specific issue:  When downloading an URL in
Chromium, we bypass WebKit.  We avoid streaming data into WebKit only to
redirect it back out of the sandboxed WebKit process.  So we need Chromium
to be able to load URLs from our main process that lives outside of the
sandbox.  This means that the blob URL support needs to be sufficiently
decoupled from WebCore (and behind the ResourceHandle interface).

Finally, I don't think there is a layering violation given the BlobRegistry
interface that Jian has created.  It provides WebCore with an interface to
inform the network layer about blobs.

-Darin


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