[webkit-dev] Blob scheme implementation

[Darin Fisher]

On Tue, Sep 14, 2010 at 10:09 PM, Adam Barth <abarth at webkit.org> wrote:

> One thing that Maciej suggested in #webkit was to interpose in the
> same way that appcache interposes.  One advantage of that approach is
> economy of mechanism.
>

I think we have mostly done this.  See BlobRegistry.


>
> (By the way, roundtrips to WebCore are cheap for the WebKit layer;
> there isn't much reason to avoid them.)
>
>
If you are referring to using Chromium's WebKit API from Chromium's browser
process, keep in mind that that really has to be done from the
in-process-webkit thread.  However, we want to handle URL requests on the IO
thread.  Having to proxy threads for this would be both cumbersome and add
undesirable latency to URL loading.  (I have data indicating that such a
thread hop is costly for loading local files.)

-Darin



> Adam
>
>
> On Tue, Sep 14, 2010 at 9:58 PM, Jian Li <jianli at chromium.org> wrote:
> > Indeed when I implement BlobResourceHandle, I have taken the range
> request
> > support into consideration and got it work. The problem is that current
> > media element implementation does not route through ResourceHandle.
> > However, introducing a ResourceHandle subclass does not sound like an
> > elegant solution given that ResoucreHandle is currently treated as a
> wrapper
> > class to the underlying platform implementation. I agree it would be
> better
> > if we could find a way to avoid extra roundtrip to pop back to WebCore to
> do
> > the real handling. But I am not sure how this could be hooked up. The
> > handling of javascript: url is somewhat special. Probably we cannot do
> the
> > similar thing as it since the handling of blob: url needs to work closely
> > with resource loader and caching layer so that we can get it work in all
> > scenarios.
> > Do you have any good suggestion on what is the right layer to hook into?
> > Does it make sense if I move the current implementation of
> > BlobResourceHandle to the underlying platform layer for WebKit mac so
> that I
> > can fix the issue with incorrect subclassing of ResourceHandle?
> > On Tue, Sep 14, 2010 at 6:21 PM, Maciej Stachowiak <mjs at apple.com>
> wrote:
> >>
> >> On Sep 14, 2010, at 6:02 PM, Adam Barth wrote:
> >>
> >> > On Tue, Sep 14, 2010 at 5:56 PM, David Levin <levin at chromium.org>
> wrote:
> >> >> 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?
> >> >>
> >> >> I don't think this is a good idea. This "re-usable module" would only
> >> >> be
> >> >> used by the Safari WebKit port. As I understand it, Chromium wouldn't
> >> >> be
> >> >> able to re-use it due to not re-using WebKit types in general. With
> >> >> only one
> >> >> port using it, the module seems like it would not be able to have a
> >> >> good
> >> >> design.
> >> >>
> >> >> So if there is a change, it seems better to just write it for the
> >> >> Safari
> >> >> WebKit port and as other ports want to implement it, if they find
> >> >> commonality, it would be in their best interest to refractor the
> >> >> existing
> >> >> code for better re-use.
> >> >
> >> > Would Chromium be able to re-use the code if it were part of WebCore?
> >> > I guess I don't understand what's different about those two cases.
> >> >
> >> > Another question, does this design allow blob URLs to be used by the
> >> > <video> element?  My understanding is that <video> bypasses
> >> > ResourceHandle because ResourceHandle isn't smart enough to handle
> >> > range requests (or something like that).
> >>
> >> At least on Mac, the media elements miss out on a number of networking
> >> features due to not going through the CachedResource layer and those
> below.
> >> For example they don't work with the app cache. It's something we'd like
> to
> >> fix eventually.
> >>
> >> Note: ResourceHandle would probably work and can handle range requests
> >> fine, but the media APIs on Mac make it tricky to fully replace the
> loading
> >> that the media framework likes to do for itself. If we had that, we
> could
> >> hook up ResourceHandle pretty easily. The cache layer would need to be
> >> enhanced to handle ranges though.
> >>
> >> Regards,
> >> Maciej
> >>
> >> _______________________________________________
> >> webkit-dev mailing list
> >> webkit-dev at lists.webkit.org
> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> >
> _______________________________________________
> 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/75b781b7/attachment.html>