[webkit-dev] Blob scheme implementation

[Jian Li]

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