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 <m...@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 <le...@chromium.org> wrote: > >> On Tue, Sep 14, 2010 at 5:42 PM, Adam Barth <aba...@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@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
