On Wed, Sep 15, 2010 at 3:31 PM, Maciej Stachowiak <m...@apple.com> wrote:
> > On Sep 15, 2010, at 1:06 PM, Darin Fisher wrote: > > On Wed, Sep 15, 2010 at 12:56 PM, Maciej Stachowiak <m...@apple.com> wrote: > >> >> On Sep 15, 2010, at 9:15 AM, Darin Fisher wrote: >> >> On Wed, Sep 15, 2010 at 8:58 AM, Alexey Proskuryakov <a...@webkit.org>wrote: >> >>> >>> 14.09.2010, в 22:15, Darin Fisher написал(а): >>> >>> > I think it makes sense to extend ResourceHandle.cpp to access the >>> BlobRegistry singleton in order to support blob URLs. >>> >>> >>> The problem I see with adding blob support to ResourceHandle is that it >>> makes it too difficult to maintain. It used to be a platform abstraction, >>> and it was hard enough to make sure it worked well across platforms. Adding >>> a significant amount of cross-platform logic on top of that isn't going to >>> make it easier - especially when it's done via subclassing. >>> >> >> I don't understand why this seems so complicated. ResourceHandle.cpp >> contains some code that is shared by all WebKit ports that can access their >> network stack directly from the WebKit main thread. It already has some >> common code for handling certain error cases (invalid URL, bad port). This >> is the best point in the code to integrate blob URL support. >> >> Maybe subclassing ResourceHandle is not the best way to go about this. It >> seems fairly clean to me, but then, I'm not sure what the alternative >> proposals look like. >> >> >> I posted a proposal yesterday (do it at the ResourceLoader layer, since >> that's how the app cache hooks in). >> > > That means that app cache doesn't work for HTML5 media in !Chromium. It > also means that blob URLs won't work for HTML5 media in !Chromium. > > > Both these things are likely to be true anyway, since most media back ends > do not even use ResourceHandle. We have a design to fix both of these things > for the Mac port, and it would not suffer from these features being at the > ResourceLoader layer. > > > >> >> >> >> >>> >>> An example that prompted me to look into this was < >>> http://trac.webkit.org/changeset/67503>. Here, a static function that >>> reported platform capabilities had to become virtual, so that it could take >>> blob loading logic into account. There is nothing in common between "are we >>> running on a version of Mac OS X that supports this" and "are we loading a >>> blob", and remembering this twist won't be easy. >>> >> >> Perhaps the static function should remain but be renamed? That way it can >> remain the function that reports platform capabilities. However, as this >> patch demonstrates, from WebCore's point of view, this needs to be a >> property of ResourceHandle. >> >> Maybe it would help if we better formalized the abstraction to the network >> stack and let ResourceHandle grow to be a smart (contains cross-platform >> helper code) front-end to that. >> >> >> I think that's not the right design. ResourceHandle is supposed to be a >> thin abstraction on top of the network library. ResourceLoader is supposed >> to be the "smart" layer. >> >> > I don't see any other examples of URL schemes being handled at the > ResourceLoader level. > > > Indeed, there aren't any. Most URL schemes do not depend on higher-level > features of the Web platform. The "blob:" scheme is not quite as magical as > "javascript:", but it is more magical than "http:". > > > I'm not thrilled to introduce more ways in which Chromium and !Chromium > differ, but integrating blob URLs at the ResourceLoader is not an option for > Chromium. > > > Chromium has made some different design choices. Often, following these to > their logical conclusion leads to designs that look like layering violations > from the pure WebKit perspective. I sympathize with the need to have a > design that's viable in the face of a process split. We are certainly > learning a lot about this as we integrate multiprocess functionality into > WebKit itself. However, as we do more of this work, I become more skeptical > that doing multiprocess actually requires quite so many layering violations, > and so I am hesitant to bend the architecture of WebKit around the desire to > do things that way. > > In fairness, we currently have networking running in the Web process, and > so have not faced down all of the issues related to I/O living in a separate > process. However, I am pretty confident that the file I/O needs for Blobs > can be handled without messing with the ResourceHandle layer, in a way that > is compatible with sandboxing. > > Maybe at some point, a few of us should get together in person to talk > about the right WebCore-level architecture to support multi-process ports > while continuing to support a single-process design and with good > abstractions and layering. > > Regards, > Maciej > > I do think it would be good to have a more in-depth face-to-face discussion about this topic. My argument boils down to the following: 1) It is valuable for downloads to go directly from network stack to file system without having to route through the sandboxed child process and back up to the non-sandboxed parent process. 2) It is valuable to have all protocols handled in one central place (excluding javascript: because it is so weird). 3) It is valuable for blob: URLs (and appcache) to work with HTML5 media. 4) Where do you draw the line? If blob: should not be handled by ResourceHandle, then what about data:, about:, or even file:? Why is it the case that those things which have nothing to do with HTTP are also implemented by ResourceHandle? I think once you start pulling on this thread, the design choices made for Chromium will begin to make sense. (Ditto for the way we have implemented appcache for Chromium.) Regards, -Darin
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev