[webkit-dev] Thoughts on reducing the complexity of WebCore
One way to reduce the complexity of WebCore without reducing the number of features in WebKit is to separate out the parts of WebCore that aren't tightly coupled to DOM/CSS/Rendering into separate (static) libraries. Consider, for example, IndexdedDB and WebAudio. These APIs are part of the web platform (or at least aspire to be part of the platform) but do not require tight coupling with many of the other concepts in WebCore. They're essentially JavaScript bindings for platform functionality (storage and audio drivers). As a non-example, flexbox would not be a good candidate to factor out of WebCore because flexbox tightly couples with CSS and layout. Here's one possible dependency diagram for how these pieces might relate. The blue boxes represent separate libraries (either static or dynamic), and the arrows represent dependencies. https://docs.google.com/drawings/d/10WlCj2J3arxf4cDGRKteNinaP755iFnmYtYtnNSCQOY/edit?hl=enauthkey=CP6plYAI The Core library contains most of what's now in WebCore. (We can come up with a better name than Core, of course.) The libraries to the left of the diagram (a few examples are shown) contain code that is today part of WebCore but that only needs to depend on Platform (e.g., not on DOM or Rendering). The Bindings layer is depicted near the top of the diagram because most concepts in WebCore have JavaScript bindings. Ideally, the bindings layer would be as thin as possible and as automatically generated as possible. Although I've drawn the dependency arrows pointing downwards, there are some upcalls in this approach. For example, Core upcalls to WebKit via Client interfaces and upcalls to Bindings via the Script objects. Moving some features into separate libraries might be an improvement over the ENABLE macros we use today because folks who are uninterested in the features can ignore the libraries entirely (e.g., not compile them or not even open them in an IDE). Unlike ENABLE macros, which can easily spider throughout the codebase, libraries are naturally more self-contained. I'm not suggesting that we move to this approach overnight, but I'm interested in your thoughts as to whether this might be a model we should consider as WebCore continues to grow in complexity. Thanks, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Thoughts on reducing the complexity of WebCore
The bindings layer isn't really on top of the Core. In particular, almost every API, however tangential, has an addition to the global Window namespace, and the Core part needs to be able to instantiate the right kind of Window object. Also, APIs that start standalone sometimes eventually grow to the point of dealing with DOM nodes of various kinds. For example, Audio will likely sooner or later interact with HTMLAudioElement. P2P may well end up having some involvement with HTMLVideoElement. Many features will also likely have interaction with the loader and the network stack. In addition, actually compiling as separate static libraries makes the build of WebCore more complicated, and likely slower (ar is slow on some platforms and does no incremental linking, so it's pure waste). For these reasons, I'm not sure making these things into separate static libraries is practical or helpful. I think isolating them to their own subdirectories is about the best we can do. Regards, Maciej On May 15, 2011, at 11:06 PM, Adam Barth wrote: One way to reduce the complexity of WebCore without reducing the number of features in WebKit is to separate out the parts of WebCore that aren't tightly coupled to DOM/CSS/Rendering into separate (static) libraries. Consider, for example, IndexdedDB and WebAudio. These APIs are part of the web platform (or at least aspire to be part of the platform) but do not require tight coupling with many of the other concepts in WebCore. They're essentially JavaScript bindings for platform functionality (storage and audio drivers). As a non-example, flexbox would not be a good candidate to factor out of WebCore because flexbox tightly couples with CSS and layout. Here's one possible dependency diagram for how these pieces might relate. The blue boxes represent separate libraries (either static or dynamic), and the arrows represent dependencies. https://docs.google.com/drawings/d/10WlCj2J3arxf4cDGRKteNinaP755iFnmYtYtnNSCQOY/edit?hl=enauthkey=CP6plYAI The Core library contains most of what's now in WebCore. (We can come up with a better name than Core, of course.) The libraries to the left of the diagram (a few examples are shown) contain code that is today part of WebCore but that only needs to depend on Platform (e.g., not on DOM or Rendering). The Bindings layer is depicted near the top of the diagram because most concepts in WebCore have JavaScript bindings. Ideally, the bindings layer would be as thin as possible and as automatically generated as possible. Although I've drawn the dependency arrows pointing downwards, there are some upcalls in this approach. For example, Core upcalls to WebKit via Client interfaces and upcalls to Bindings via the Script objects. Moving some features into separate libraries might be an improvement over the ENABLE macros we use today because folks who are uninterested in the features can ignore the libraries entirely (e.g., not compile them or not even open them in an IDE). Unlike ENABLE macros, which can easily spider throughout the codebase, libraries are naturally more self-contained. I'm not suggesting that we move to this approach overnight, but I'm interested in your thoughts as to whether this might be a model we should consider as WebCore continues to grow in complexity. Thanks, 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] New feature announcement – Video conferencing and peer-to-peer communication
The plan is to have the P2P VC WebKit code to do as little as possible and leave the implementation to the browser port, just like the MediaStream patches. And the code touches very little other code; Event, EventTarget, Navigator etc but obviously heavily depends on the MediaStream functionality. Is this a problem? Happy to modularize the functionality if someone can give me some pointers, show our work in progress etc. To get the standard (on whatwg) finalized an implementation is needed so that some real world usage can be had, and previously we have received some favorable comments re go-ahead on implementation. Personally I think this is a great feature and are committed to implement it properly. /Tommy On Sat, May 14, 2011 at 01:50, Adam Barth aba...@webkit.org wrote: One approach we talked about at the contributor's meeting to dealing with the ever-growing feature list of WebCore is modularity. Looking at the specification for this feature, there doesn't seem to be much interdependence between these APIs and the rest of WebCore. For example, there's nothing that couples with dom, css, or rendering. Would it make sense to try building this feature as a self-contained module? For example, you could imagine the following dependency diagram: WebKit - WebP2P | | | \/ + WebCore Ideally, WebCore would have some moderately well-defined interface for these modules, much like the WebKit -- WebCore interaction is mediated by clients. Ideally, these modules would just describe themselves using WebIDL and we could just generated bindings for them. As another example, webaudio might also profit from such as design. Of course, splitting this feature off into its own module doesn't remove all the costs of the new feature, but it would make it easier to work on WebCore proper without having to deal with all the complexities of every feature. Adam On Fri, May 13, 2011 at 11:10 AM, Eric Seidel e...@webkit.org wrote: That sounds like about 8 features. Seems we should think about this in smaller chunks... On the surface peer to peer video conferencing does not seem like something appropriate to add to WebCore/WebKit. Just like an API for reading my email is out of scope for the project. (But certainly lots of people build such things on top of WebKit.) :) -eric On Fri, May 13, 2011 at 6:19 AM, Tony Gentilcore to...@chromium.org wrote: For those interested, the cover bug for this work is here: https://bugs.webkit.org/show_bug.cgi?id=56459 -Tony On Fri, May 13, 2011 at 8:27 AM, Adam Bergkvist adam.bergkv...@ericsson.com wrote: I want to inform people on this list that we have been doing some early implementation work of the video conferencing and peer-to-peer communication chapter in the HTML spec (http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#video-conferencing-and-peer-to-peer-communication). This section of the spec is in an early stage and should be considered experimental, but as it becomes more understood, we intend to contribute to the WebKit implementation. Others are also (based on bugs reported) working on this. BR 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 ___ 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 -- Tommy Widenflycht, Senior Software Engineer Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden Org. nr. 556656-6880 This email may be confidential or privileged. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it went to the wrong person. Thanks! And yes, I have to include this message in every outgoing email according to EU law. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Glyph data in Rendering Text
Hi I want to find out where does webkit saves the glyph data of characters and read from it? I think when it renders text it should first render bitmap of the characters and use the measuring data to do layout. I went trough lots of objects but no success. Soheil Servati Beiragh PhD Candidate, ECE Department, Research Center for Integrated Microsystems, University of Windsor. Room 268 Essex Hall 401 Sunset Avenue Windsor, Ontario Canada, N9B 3P4 Phone: 519-253-3000 Ext 3396 Email: serv...@uwindsor.ca___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Glyph data in Rendering Text
Hi I want to find out where does webkit saves the glyph data of characters and read from it? I think when it renders text it should first render bitmap of the characters and use the measuring data to do layout. I went trough lots of objects but no success. Soheil Servati Beiragh PhD Candidate, ECE Department, Research Center for Integrated Microsystems, University of Windsor. Room 268 Essex Hall 401 Sunset Avenue Windsor, Ontario Canada, N9B 3P4 Phone: 519-253-3000 Ext 3396 Email: serv...@uwindsor.ca___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Glyph data in Rendering Text
Hi I want to find out where does webkit saves the glyph data of characters and read from it? I think when it renders text it should first render bitmap of the characters and use the measuring data to do layout. I went trough lots of objects but no success. Soheil Servati Beiragh PhD Candidate, ECE Department, Research Center for Integrated Microsystems, University of Windsor. Room 268 Essex Hall 401 Sunset Avenue Windsor, Ontario Canada, N9B 3P4 Phone: 519-253-3000 Ext 3396 Email: serv...@uwindsor.ca___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Thoughts on reducing the complexity of WebCore
On Mon, May 16, 2011 at 2:59 AM, Maciej Stachowiak m...@apple.com wrote: The bindings layer isn't really on top of the Core. In particular, almost every API, however tangential, has an addition to the global Window namespace, and the Core part needs to be able to instantiate the right kind of Window object. The specs for these features use the Supplemental attribute in WebIDL to solve problem. Also, APIs that start standalone sometimes eventually grow to the point of dealing with DOM nodes of various kinds. For example, Audio will likely sooner or later interact with HTMLAudioElement. P2P may well end up having some involvement with HTMLVideoElement. Many features will also likely have interaction with the loader and the network stack. Yeah, for a while I had a dependency from the standalone APIs to Core (e.g., in the ASCII diagram in the P2P thread), but looking through the code that seemed like good candidates for this model, I didn't actually seem that many dependencies. Of course, that doesn't mean they won't be added in the future. The loader is certainly a complex area here, but, from my point of view, that points to improvements we should make in the loader. In addition, actually compiling as separate static libraries makes the build of WebCore more complicated, and likely slower (ar is slow on some platforms and does no incremental linking, so it's pure waste). For these reasons, I'm not sure making these things into separate static libraries is practical or helpful. I think isolating them to their own subdirectories is about the best we can do. Ok. Thanks for taking the time to provide feedback. Adam On May 15, 2011, at 11:06 PM, Adam Barth wrote: One way to reduce the complexity of WebCore without reducing the number of features in WebKit is to separate out the parts of WebCore that aren't tightly coupled to DOM/CSS/Rendering into separate (static) libraries. Consider, for example, IndexdedDB and WebAudio. These APIs are part of the web platform (or at least aspire to be part of the platform) but do not require tight coupling with many of the other concepts in WebCore. They're essentially JavaScript bindings for platform functionality (storage and audio drivers). As a non-example, flexbox would not be a good candidate to factor out of WebCore because flexbox tightly couples with CSS and layout. Here's one possible dependency diagram for how these pieces might relate. The blue boxes represent separate libraries (either static or dynamic), and the arrows represent dependencies. https://docs.google.com/drawings/d/10WlCj2J3arxf4cDGRKteNinaP755iFnmYtYtnNSCQOY/edit?hl=enauthkey=CP6plYAI The Core library contains most of what's now in WebCore. (We can come up with a better name than Core, of course.) The libraries to the left of the diagram (a few examples are shown) contain code that is today part of WebCore but that only needs to depend on Platform (e.g., not on DOM or Rendering). The Bindings layer is depicted near the top of the diagram because most concepts in WebCore have JavaScript bindings. Ideally, the bindings layer would be as thin as possible and as automatically generated as possible. Although I've drawn the dependency arrows pointing downwards, there are some upcalls in this approach. For example, Core upcalls to WebKit via Client interfaces and upcalls to Bindings via the Script objects. Moving some features into separate libraries might be an improvement over the ENABLE macros we use today because folks who are uninterested in the features can ignore the libraries entirely (e.g., not compile them or not even open them in an IDE). Unlike ENABLE macros, which can easily spider throughout the codebase, libraries are naturally more self-contained. I'm not suggesting that we move to this approach overnight, but I'm interested in your thoughts as to whether this might be a model we should consider as WebCore continues to grow in complexity. Thanks, 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] Thoughts on reducing the complexity of WebCore
On May 16, 2011, at 10:08 AM, Adam Barth wrote: On Mon, May 16, 2011 at 2:59 AM, Maciej Stachowiak m...@apple.com wrote: The bindings layer isn't really on top of the Core. In particular, almost every API, however tangential, has an addition to the global Window namespace, and the Core part needs to be able to instantiate the right kind of Window object. The specs for these features use the Supplemental attribute in WebIDL to solve problem. That solves the spec problem, but this doesn't automatically solve the code-level problem. Also, APIs that start standalone sometimes eventually grow to the point of dealing with DOM nodes of various kinds. For example, Audio will likely sooner or later interact with HTMLAudioElement. P2P may well end up having some involvement with HTMLVideoElement. Many features will also likely have interaction with the loader and the network stack. Yeah, for a while I had a dependency from the standalone APIs to Core (e.g., in the ASCII diagram in the P2P thread), but looking through the code that seemed like good candidates for this model, I didn't actually seem that many dependencies. Of course, that doesn't mean they won't be added in the future. The loader is certainly a complex area here, but, from my point of view, that points to improvements we should make in the loader. In addition, actually compiling as separate static libraries makes the build of WebCore more complicated, and likely slower (ar is slow on some platforms and does no incremental linking, so it's pure waste). For these reasons, I'm not sure making these things into separate static libraries is practical or helpful. I think isolating them to their own subdirectories is about the best we can do. Ok. Thanks for taking the time to provide feedback. Another issue is that it's not obvious these features are getting in the way. In my own work in WebCore, I've never had to worry about the indexedb or audio api stuff, except for when I want to change things related to WTF classes, or in the way they affect my link time. It seems like, under the static library plan, that would continue to be true. IndexedDB does somewhat clutter the storage directory, since it is piled in there with all other storage APIs, but just putting it in a separate directory under WebCore would get it out of the way. Maybe others have different experiences. The things that do get in the way a lot are optional features that are really intrusive in core code, like WML. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Progressing on the Android port
On Fri, May 13, 2011 at 1:48 PM, Lucas De Marchi lucas.demar...@profusion.mobi wrote: On Fri, May 13, 2011 at 5:35 PM, Holger Freyther ze...@selfish.org wrote: On 05/12/2011 05:16 PM, Lucas De Marchi wrote: Hi Holger Freyther, I'm glad to hear you will use CMake as the build system. Take a look on the email I sent yesterday porting GTK to CMake, maybe it will help you. Since Android and Chromium/Linux have overlaps, do you think it'd be easy to build the Chromium port as well? I am not sure about Chromium. When one tries to build Chromium a lot of external code will be downloaded, I don't have the things in my tree right now but IIRC these external modules are all having Gyp files so one would need to convert these dependencies and it will be quite some work. Hummn... too bad. Looking at the gyp files, it doesn't seem difficult to convert them. But indeed it's quite some work. Keep in mind that you'd also need to repeat this exercise whenever you update to the latest version of those modules. If you are planning to make use of more of the same code as Chromium, I suspect you will find that using GYP will be the path of least resistance. Regards, -Darin I am having one specific issue with CMake right now, do you think it would be possible to have defaults for WEBKIT_FEATURE(ENABLE_AS_IMAGE Enable SVG as image DEFAULT ON SVG)? E.g. I need to define ENABLE_GLIB as otherwise I end up having a '#define ENABLE_GLIB' in the cmakeconfig.h breaking the build. This is exactly the reason why I committed r86370 when doing the GTK port. Now you can do as I did for GTK: WEBKIT_FEATURE(ENABLE_GLIB_SUPPORT Enable Glib support ALWAYS ON) or ALWAYS OFF if you meant to unconditionally disable it. regards, Lucas De Marchi ___ 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] New feature announcement – Video conferencing and peer-to-peer communication
On Mon, May 16, 2011 at 6:54 AM, Tommy Widenflycht tom...@google.com wrote: The plan is to have the P2P VC WebKit code to do as little as possible and leave the implementation to the browser port, just like the MediaStream patches. And the code touches very little other code; Event, EventTarget, Navigator etc but obviously heavily depends on the MediaStream functionality. There's a trade-off here between adding complexity to WebCore and sharing the functionality between different consumers of WebKit. Is this a problem? Happy to modularize the functionality if someone can give me some pointers, show our work in progress etc. I started a separate thread about modularity. That's somewhat of a larger discussion, and certainly doesn't need to block your work. It's unclear whether that's the direction the project will go in any case. In the near-term, I'd recommend putting this feature in a new directory and being careful about dependencies to and from your code. To get the standard (on whatwg) finalized an implementation is needed so that some real world usage can be had, and previously we have received some favorable comments re go-ahead on implementation. Personally I think this is a great feature and are committed to implement it properly. The high-level question is whether this feature is beneficial to the WebKit project. I've seen folks raise the following concerns: 1) Eric Seidel raised the question of whether this feature is appropriate for WebCore/WebKit, presumably because P2P video conferencing seems like something you'd build on top of the web platform (like an email service) rather than something that's directly related to rendering web pages. 2) Eric Carlson (in Bug 56459) says that the feature is important for WebKit but is concerned that the spec is a moving target and that implementing it at this stage might be costly for the project in the log run. After some discussion, he seems to agree that we should proceed with an off-by-default, vendor-prefixed implementation so we can provide feedback about our implementation experience to the standards process. My perspective is that I would like to see WebKit continue to be a leading implementation of the web platform. Leading is more expensive than following, of course, because followers can adopt a wait-and-see approach and only implement features that are already successful rather than placing bets that sometimes pay off and sometimes don't. From that perspective, the question boils down to whether this feature is a good bet for the platform. Adam On Sat, May 14, 2011 at 01:50, Adam Barth aba...@webkit.org wrote: One approach we talked about at the contributor's meeting to dealing with the ever-growing feature list of WebCore is modularity. Looking at the specification for this feature, there doesn't seem to be much interdependence between these APIs and the rest of WebCore. For example, there's nothing that couples with dom, css, or rendering. Would it make sense to try building this feature as a self-contained module? For example, you could imagine the following dependency diagram: WebKit - WebP2P | | | \/ + WebCore Ideally, WebCore would have some moderately well-defined interface for these modules, much like the WebKit -- WebCore interaction is mediated by clients. Ideally, these modules would just describe themselves using WebIDL and we could just generated bindings for them. As another example, webaudio might also profit from such as design. Of course, splitting this feature off into its own module doesn't remove all the costs of the new feature, but it would make it easier to work on WebCore proper without having to deal with all the complexities of every feature. Adam On Fri, May 13, 2011 at 11:10 AM, Eric Seidel e...@webkit.org wrote: That sounds like about 8 features. Seems we should think about this in smaller chunks... On the surface peer to peer video conferencing does not seem like something appropriate to add to WebCore/WebKit. Just like an API for reading my email is out of scope for the project. (But certainly lots of people build such things on top of WebKit.) :) -eric On Fri, May 13, 2011 at 6:19 AM, Tony Gentilcore to...@chromium.org wrote: For those interested, the cover bug for this work is here: https://bugs.webkit.org/show_bug.cgi?id=56459 -Tony On Fri, May 13, 2011 at 8:27 AM, Adam Bergkvist adam.bergkv...@ericsson.com wrote: I want to inform people on this list that we have been doing some early implementation work of the video conferencing and peer-to-peer communication chapter in the HTML spec (http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#video-conferencing-and-peer-to-peer-communication). This section of the spec is in an early stage and should be considered experimental, but as it becomes more understood, we intend to contribute to the
Re: [webkit-dev] New feature announcement – Video conferencing and peer-to-peer communication
On Fri, 13 May 2011, Eric Seidel wrote: On the surface peer to peer video conferencing does not seem like something appropriate to add to WebCore/WebKit. Just like an API for reading my email is out of scope for the project. (But certainly lots of people build such things on top of WebKit.) :) What people are talking about as video conferencing and peer-to-peer communication here really are the building blocks for letting people build such things on top of the Web platform. The relevant part of the HTML spec is basically just these features: - A way to get input from the system camera(s) and microphone(s). - A way for two peers to connect and exchange data and audio/video streams directly, reusing the widely used ICE, STUN, TURN, and SDP technologies, assuming they have an existing indirect channel. - A way to record or display these streams. Actually deploying a video conferencing system would need far more than this. For example, you need identity and presence, which are not part of the Web platform but have to be built on top of it. You also need to actually implement the existing indirect channel mentioned above (e.g. using XHR or WebSockets), and you need to provide the STUN and TURN servers in the cloud. The components that are provided by this part of the HTML spec have other purposes beyond video conferencing; for example you can use the access to local camera and microphones for augmented reality tools, you can use the peer-to-peer component for exchanging real-time game state data in a video game, and you can use the recording component for recording video blogs. The parallel to e-mail apps is apt: it is much like how the platform provides XHR, input controls, and local storage, all necessary components for an e-mail app, but does not provide an e-mail app component; and the components it does provide can be similarly reused in other contexts. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] 6th Annual WebKit Open Source Party!
Hi all, It has been another great year for the WebKit project, and it's time to celebrate! Apple's Safari/WebKit team will be hosting the 6th Annual WebKit Open Source Party in San Francisco during WWDC. All members of the WebKit community are invited. So please encourage all of your WebKit-hacking, #webkit-chatting, bug-filing friends to join us! When: Wednesday, June 8th, 7pm Where: Billiards Room @ Jillian's (101 Fourth St, Suite 170, San Francisco, CA 94103) Who:Members of the WebKit Community What: Food, drinks, and good company Feel free to email me if you have any questions. - Adele Peterson ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
