[webkit-dev] Blob scheme implementation

[Maciej Stachowiak]

On Sep 14, 2010, at 9:58 PM, Jian Li 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?

Subclassing ResourceHandle is somewhat inelegant. It's not a class designed to be subclassed, and subclassing it correctly probably requires making more methods virtual. In addition, since the blob: URL scheme implementation needs to know about other parts of WebCore outside the platform/ directory, it's a bit of a layering violation to have a ResouceHandle subclass dealing with it.

One (maybe slightly odd) thought that came to me is that perhaps blob: can be handled at the ResourceLoader level. That is the level where higher-level concepts are allowed to take over the load - for example, app cache hooks in at this layer, as does WebArchive loading, and also the ability to load a premade data chunk as a web page instead of loading an actual URL. So in that regard, it's a natural place for higher-level Web platform concepts to take over the load. This would be different from the way we handle any other URL scheme, but one way or another, blob: needs to be special, so maybe that's ok.

Regards,
Maciej


> 
> 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/8380bb77/attachment.html>