Re: [webkit-dev] Blob scheme implementation
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
Re: [webkit-dev] Blob scheme implementation
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. 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. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Blob scheme implementation
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. 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. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Blob scheme implementation
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). 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. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Blob scheme implementation
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.orgwrote: 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. 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. 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. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Blob scheme implementation
On Wed, Sep 15, 2010 at 1:06 PM, Darin Fisher da...@chromium.org 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.orgwrote: 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. 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. I'm ignoring javascript: URLs because they are super weird... evaluation happens synchronously and can have side effects such as causing other navigations. It does not fit the normal mold of URL loading. Mozilla tries to express javascript: URLs as a protocol handler, and it only adds complexity. The WebKit approach of implementing javascript: URLs as special cases in FrameLoader is superior because it makes the code easier to understand. -Darin 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. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Blob scheme implementation
On Wed, Sep 15, 2010 at 9:15 AM, Darin Fisher da...@chromium.org wrote: On Wed, Sep 15, 2010 at 8:58 AM, Alexey Proskuryakov a...@webkit.orgwrote: 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. 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. +1 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. AppCache loading has been mentioned a couple times in this thread. Really, the points of integration between the loader and the appcache are mostly smoke and mirrors in chrome... loading out of an appcache actually happens via ResourceHandle in our port. Webcore's webarchive loading wouldn't work in a sandboxed renderer either. I'm working up to a similar 'where to put what code' conundrum around xhr.responseBlob. Ideally, I'd like ResourceHandle to produce the blob. ResourceHandle vs PlatformResourceHandle, maybe a class like the latter could have a 'capabilities' interface that allowed common code to query things like 'CanProvideResponseBlobs' and if not provides that capability in common code. Similarly a 'CanHandleBlobScheme' capability query could provide a fork in the road for loading blob urls (so the common code impl would poke at the BlobRegistry singleton). Subclassing ResourceHandle for blob url loading is probably not the most elegant thing, but given the current state of the code base, it's not a bad option. This schism around ResourceHandle in particular is a recurring theme. The recurring answer do it in the loader just doesn't work so well for us. -Darin ___ 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
Re: [webkit-dev] Blob scheme implementation
On Wed, Sep 15, 2010 at 1:09 PM, Darin Fisher da...@chromium.org wrote: I'm ignoring javascript: URLs because they are super weird... evaluation happens synchronously and can have side effects such as causing other navigations. It does not fit the normal mold of URL loading. Mozilla tries to express javascript: URLs as a protocol handler, and it only adds complexity. The WebKit approach of implementing javascript: URLs as special cases in FrameLoader is superior because it makes the code easier to understand. Oh man. If our JavaScript URL handling is easier to understand than Firefox's, I'd be really scared to see theirs. :) Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Blob scheme implementation
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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Blob scheme implementation
On Sep 15, 2010, at 2:05 PM, Adam Barth wrote: On Wed, Sep 15, 2010 at 1:09 PM, Darin Fisher da...@chromium.org wrote: I'm ignoring javascript: URLs because they are super weird... evaluation happens synchronously and can have side effects such as causing other navigations. It does not fit the normal mold of URL loading. Mozilla tries to express javascript: URLs as a protocol handler, and it only adds complexity. The WebKit approach of implementing javascript: URLs as special cases in FrameLoader is superior because it makes the code easier to understand. Oh man. If our JavaScript URL handling is easier to understand than Firefox's, I'd be really scared to see theirs. :) If you do decide to read it, I promise to visit you regularly at the asylum. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Blob scheme implementation
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.orgwrote: 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
[webkit-dev] Blob scheme implementation
Jian Li just had a conversation in #webkit about where the code for implementing the Blob URL scheme should live. I thought I'd open the discussion to webkit-dev in case folks had a different perspective. As part of the fileapi, we're introducing a new URL scheme, called blob, which represents a bucket of bits, usually from a file, but potentially from another location. Assigning these objects URL is helpful because then they integrate with the rest of the web platform. For example, you can use them as images via the img element or videos via the video element, etc. Currently, the blob URL scheme is implemented with a subclass of ResourceHandle (our primary network abstraction) called BlobResourceHandle. My sense is that this isn't the right place in the architecture to add support for the blob URL scheme. The issue is that each port has a table somewhere that maps URL schemes to networking backends. In Chromium, for example, that mapping is provided by URLRequestFactory, which lives in the net module. By implementing the blob URL scheme at the ResourceHandle layer, we're short-circuiting that table. In some sense, this is analogous to adding an HTTPResourceHandle and implementing the HTTP protocol inside of WebCore. While its true that most (all?) users of WebKit will need to wire WebCore up to an HTTP library, that doesn't necessarily mean that WebCore should contain an implementation of the HTTP protocol. In the same way, even if a large number of WebKit users will wish to support the blob URL scheme, that doesn't necessarily mean that WebCore should contain an implementation of the scheme. I can certainly see the appeal of sharing the blob URL implementation code between different ports of WebKit, but we can achieve that goal in a number of ways, including creating an external library or a separate BlobCore module. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Blob scheme implementation
When I implemented the blob scheme handling, I intentionally tried to have some common implementation that could be used by all applicable platforms. But it seems that introducing BlobResourceHandle derived from ResourceHandle might not be a good hook up point because ResourceHandle is only a wrapper around the platform loading logics. To fix this problem, I can move all the blob handling logic to the platform specific layer (for WebKit mac) and it is up to other individual platform to implement it when needed. Jian On Tue, Sep 14, 2010 at 5:22 PM, Adam Barth aba...@webkit.org wrote: Jian Li just had a conversation in #webkit about where the code for implementing the Blob URL scheme should live. I thought I'd open the discussion to webkit-dev in case folks had a different perspective. As part of the fileapi, we're introducing a new URL scheme, called blob, which represents a bucket of bits, usually from a file, but potentially from another location. Assigning these objects URL is helpful because then they integrate with the rest of the web platform. For example, you can use them as images via the img element or videos via the video element, etc. Currently, the blob URL scheme is implemented with a subclass of ResourceHandle (our primary network abstraction) called BlobResourceHandle. My sense is that this isn't the right place in the architecture to add support for the blob URL scheme. The issue is that each port has a table somewhere that maps URL schemes to networking backends. In Chromium, for example, that mapping is provided by URLRequestFactory, which lives in the net module. By implementing the blob URL scheme at the ResourceHandle layer, we're short-circuiting that table. In some sense, this is analogous to adding an HTTPResourceHandle and implementing the HTTP protocol inside of WebCore. While its true that most (all?) users of WebKit will need to wire WebCore up to an HTTP library, that doesn't necessarily mean that WebCore should contain an implementation of the HTTP protocol. In the same way, even if a large number of WebKit users will wish to support the blob URL scheme, that doesn't necessarily mean that WebCore should contain an implementation of the scheme. I can certainly see the appeal of sharing the blob URL implementation code between different ports of WebKit, but we can achieve that goal in a number of ways, including creating an external library or a separate BlobCore module. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Blob scheme implementation
What do you think of the idea of having a re-useable BlobCore module that all the ports can share? Adam On Tue, Sep 14, 2010 at 5:39 PM, Jian Li jia...@chromium.org wrote: When I implemented the blob scheme handling, I intentionally tried to have some common implementation that could be used by all applicable platforms. But it seems that introducing BlobResourceHandle derived from ResourceHandle might not be a good hook up point because ResourceHandle is only a wrapper around the platform loading logics. To fix this problem, I can move all the blob handling logic to the platform specific layer (for WebKit mac) and it is up to other individual platform to implement it when needed. Jian On Tue, Sep 14, 2010 at 5:22 PM, Adam Barth aba...@webkit.org wrote: Jian Li just had a conversation in #webkit about where the code for implementing the Blob URL scheme should live. I thought I'd open the discussion to webkit-dev in case folks had a different perspective. As part of the fileapi, we're introducing a new URL scheme, called blob, which represents a bucket of bits, usually from a file, but potentially from another location. Assigning these objects URL is helpful because then they integrate with the rest of the web platform. For example, you can use them as images via the img element or videos via the video element, etc. Currently, the blob URL scheme is implemented with a subclass of ResourceHandle (our primary network abstraction) called BlobResourceHandle. My sense is that this isn't the right place in the architecture to add support for the blob URL scheme. The issue is that each port has a table somewhere that maps URL schemes to networking backends. In Chromium, for example, that mapping is provided by URLRequestFactory, which lives in the net module. By implementing the blob URL scheme at the ResourceHandle layer, we're short-circuiting that table. In some sense, this is analogous to adding an HTTPResourceHandle and implementing the HTTP protocol inside of WebCore. While its true that most (all?) users of WebKit will need to wire WebCore up to an HTTP library, that doesn't necessarily mean that WebCore should contain an implementation of the HTTP protocol. In the same way, even if a large number of WebKit users will wish to support the blob URL scheme, that doesn't necessarily mean that WebCore should contain an implementation of the scheme. I can certainly see the appeal of sharing the blob URL implementation code between different ports of WebKit, but we can achieve that goal in a number of ways, including creating an external library or a separate BlobCore module. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Blob scheme implementation
I think it is a good idea but it will involve lots of work to figure out how to build and test such module that could be used by all the ports. My concern is that I do not have enough resource to speak of for all other ports. Thanks. 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? Adam On Tue, Sep 14, 2010 at 5:39 PM, Jian Li jia...@chromium.org wrote: When I implemented the blob scheme handling, I intentionally tried to have some common implementation that could be used by all applicable platforms. But it seems that introducing BlobResourceHandle derived from ResourceHandle might not be a good hook up point because ResourceHandle is only a wrapper around the platform loading logics. To fix this problem, I can move all the blob handling logic to the platform specific layer (for WebKit mac) and it is up to other individual platform to implement it when needed. Jian On Tue, Sep 14, 2010 at 5:22 PM, Adam Barth aba...@webkit.org wrote: Jian Li just had a conversation in #webkit about where the code for implementing the Blob URL scheme should live. I thought I'd open the discussion to webkit-dev in case folks had a different perspective. As part of the fileapi, we're introducing a new URL scheme, called blob, which represents a bucket of bits, usually from a file, but potentially from another location. Assigning these objects URL is helpful because then they integrate with the rest of the web platform. For example, you can use them as images via the img element or videos via the video element, etc. Currently, the blob URL scheme is implemented with a subclass of ResourceHandle (our primary network abstraction) called BlobResourceHandle. My sense is that this isn't the right place in the architecture to add support for the blob URL scheme. The issue is that each port has a table somewhere that maps URL schemes to networking backends. In Chromium, for example, that mapping is provided by URLRequestFactory, which lives in the net module. By implementing the blob URL scheme at the ResourceHandle layer, we're short-circuiting that table. In some sense, this is analogous to adding an HTTPResourceHandle and implementing the HTTP protocol inside of WebCore. While its true that most (all?) users of WebKit will need to wire WebCore up to an HTTP library, that doesn't necessarily mean that WebCore should contain an implementation of the HTTP protocol. In the same way, even if a large number of WebKit users will wish to support the blob URL scheme, that doesn't necessarily mean that WebCore should contain an implementation of the scheme. I can certainly see the appeal of sharing the blob URL implementation code between different ports of WebKit, but we can achieve that goal in a number of ways, including creating an external library or a separate BlobCore module. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Blob scheme implementation
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. dave Adam On Tue, Sep 14, 2010 at 5:39 PM, Jian Li jia...@chromium.org wrote: When I implemented the blob scheme handling, I intentionally tried to have some common implementation that could be used by all applicable platforms. But it seems that introducing BlobResourceHandle derived from ResourceHandle might not be a good hook up point because ResourceHandle is only a wrapper around the platform loading logics. To fix this problem, I can move all the blob handling logic to the platform specific layer (for WebKit mac) and it is up to other individual platform to implement it when needed. Jian On Tue, Sep 14, 2010 at 5:22 PM, Adam Barth aba...@webkit.org wrote: Jian Li just had a conversation in #webkit about where the code for implementing the Blob URL scheme should live. I thought I'd open the discussion to webkit-dev in case folks had a different perspective. As part of the fileapi, we're introducing a new URL scheme, called blob, which represents a bucket of bits, usually from a file, but potentially from another location. Assigning these objects URL is helpful because then they integrate with the rest of the web platform. For example, you can use them as images via the img element or videos via the video element, etc. Currently, the blob URL scheme is implemented with a subclass of ResourceHandle (our primary network abstraction) called BlobResourceHandle. My sense is that this isn't the right place in the architecture to add support for the blob URL scheme. The issue is that each port has a table somewhere that maps URL schemes to networking backends. In Chromium, for example, that mapping is provided by URLRequestFactory, which lives in the net module. By implementing the blob URL scheme at the ResourceHandle layer, we're short-circuiting that table. In some sense, this is analogous to adding an HTTPResourceHandle and implementing the HTTP protocol inside of WebCore. While its true that most (all?) users of WebKit will need to wire WebCore up to an HTTP library, that doesn't necessarily mean that WebCore should contain an implementation of the HTTP protocol. In the same way, even if a large number of WebKit users will wish to support the blob URL scheme, that doesn't necessarily mean that WebCore should contain an implementation of the scheme. I can certainly see the appeal of sharing the blob URL implementation code between different ports of WebKit, but we can achieve that goal in a number of ways, including creating an external library or a separate BlobCore module. Adam ___ 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
Re: [webkit-dev] Blob scheme implementation
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). Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Blob scheme implementation
On Tue, Sep 14, 2010 at 6:02 PM, Adam Barth aba...@webkit.org 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. No. As David said, one reason is to avoid incurring the unnecessary cost of converting between WebCore type data and Chromium type data. 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). Unfortunately it does not work for video elements since they're loaded in different code path. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Blob scheme implementation
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
Re: [webkit-dev] Blob scheme implementation
On Sep 14, 2010, at 5:56 PM, David Levin 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. What about Gtk, Qt, Wx, Efl...? Where possible these days we seem to implement a single impl in webcore that is used by everyone --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Blob scheme implementation
On Tue, Sep 14, 2010 at 6:53 PM, Oliver Hunt oli...@apple.com wrote: On Sep 14, 2010, at 5:56 PM, David Levin 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. What about Gtk, Qt, Wx, Efl...? Where possible these days we seem to implement a single impl in webcore that is used by everyone Indeed, it is a worthy goal. In fact, the current implementation does that, but there were some concerns about how it was accomplished. So Adam's proposal is to implement a re-usable module which is wired up by each individual port down in the port's specific implementation by each platform's maintainers. I was simply remarking that it doesn't seem good to start out with a generalization that only one port is using. (In the past when I've done generalizations of this sort, it tends to be too generic and a lot more complicated/complex than necessary.) Instead if the code were just done for WebKit OSX, when a second port starts to do something, it could break out the code that is generic because that would result in a design that is done at the right level. dave --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Blob scheme implementation
On Tue, Sep 14, 2010 at 5:52 PM, Maciej Stachowiak m...@apple.com wrote: On Sep 14, 2010, at 5:22 PM, Adam Barth wrote: In some sense, this is analogous to adding an HTTPResourceHandle and implementing the HTTP protocol inside of WebCore. While its true that most (all?) users of WebKit will need to wire WebCore up to an HTTP library, that doesn't necessarily mean that WebCore should contain an implementation of the HTTP protocol. In the same way, even if a large number of WebKit users will wish to support the blob URL scheme, that doesn't necessarily mean that WebCore should contain an implementation of the scheme. I can certainly see the appeal of sharing the blob URL implementation code between different ports of WebKit, but we can achieve that goal in a number of ways, including creating an external library or a separate BlobCore module. I'm not sure about this. The reason WebKit defers to a port-specific library for networking originally stemmed from the desire to integrate with existing libraries that might have non-Web clients. While this has some benefits, it also has some costs - many aspects of the HTTP stack have compatibility impact and so WebKit-based browsers vary more in their Web-facing behavior than they would otherwise. In the case of the blob: scheme, my understanding is that it makes no sense outside the browser context, and has tight interactions with other parts of the platform - for instance, my understanding is that blob: URLs are not permanent but rather may cease to be valid as some point (correct me if I'm wrong). This makes me think that blob: URLs are maybe more like javascript: URLs, in that trying to make them part of the network library would actually produce layering violations rather than resolving them, and would not in practice benefit non-browser clients of those libraries. Threading javascript: URLs through the network stack only to pop back to WebCore to do the actual processing would be silly. I think maybe blob: is the same way, though to a lesser degree. Regard, Maciej The key issue, which I think has been touched on elsewhere in this thread, is HTML5 media. Since that doesn't use ResourceHandle, it is necessary for blob URLs to be integrated at a lower level so that the HTML5 media engine can access them. There is also another Chromium specific issue: When downloading an URL in Chromium, we bypass WebKit. We avoid streaming data into WebKit only to redirect it back out of the sandboxed WebKit process. So we need Chromium to be able to load URLs from our main process that lives outside of the sandbox. This means that the blob URL support needs to be sufficiently decoupled from WebCore (and behind the ResourceHandle interface). Finally, I don't think there is a layering violation given the BlobRegistry interface that Jian has created. It provides WebCore with an interface to inform the network layer about blobs. -Darin ___ 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
Re: [webkit-dev] Blob scheme implementation
One thing that Maciej suggested in #webkit was to interpose in the same way that appcache interposes. One advantage of that approach is economy of mechanism. (By the way, roundtrips to WebCore are cheap for the WebKit layer; there isn't much reason to avoid them.) Adam On Tue, Sep 14, 2010 at 9:58 PM, Jian Li jia...@chromium.org 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? 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
Re: [webkit-dev] Blob scheme implementation
I think it makes sense to extend ResourceHandle.cpp to access the BlobRegistry singleton in order to support blob URLs. This will work for all ports that use ResourceHandle.cpp (everyone except Chromium AFAIK). I don't think we need to overabstract this. When designing this system, we took a hard look at how we could make Chromium reuse a WebCore implementation of BlobRegistry and BlobResourceHandle, but it just isn't a good match for Chromium's network stack. We need to subclass URLRequestJob (defined in Chromium's network stack), and it would just be a big mess to convert between WebCore types and Chromium types. The amount of code that could be shared would be so small that it just didn't seem worth it. -Darin On Tue, Sep 14, 2010 at 9:58 PM, Jian Li jia...@chromium.org 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? 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Blob scheme implementation
On Tue, Sep 14, 2010 at 10:09 PM, Adam Barth aba...@webkit.org wrote: One thing that Maciej suggested in #webkit was to interpose in the same way that appcache interposes. One advantage of that approach is economy of mechanism. I think we have mostly done this. See BlobRegistry. (By the way, roundtrips to WebCore are cheap for the WebKit layer; there isn't much reason to avoid them.) If you are referring to using Chromium's WebKit API from Chromium's browser process, keep in mind that that really has to be done from the in-process-webkit thread. However, we want to handle URL requests on the IO thread. Having to proxy threads for this would be both cumbersome and add undesirable latency to URL loading. (I have data indicating that such a thread hop is costly for loading local files.) -Darin Adam On Tue, Sep 14, 2010 at 9:58 PM, Jian Li jia...@chromium.org 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? 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
