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
