Re: [webkit-dev] Announcing WebKit2
Hi, What's the status of Webkit2? I've built the latest webkit version on Windows with --webkit2 option and I see that there is only one process shown in Task Manager irrespective of the number of Windows that I open. Reagrds, Nayan. On 4/13/10, Geoffrey Garen gga...@apple.com wrote: Will I be able to adjust process priorities to keep all processes of a certain MIME type (say application/x-shockwave-flash) to receive no more than 15% cpu time or monitor its memory usage? All process management is behind the API layer, the goal being to shield app developers from the details of process management. I'm not sure how you'd control the details of process management. Geoff -- Regards, _Nayan_ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
Date: Wed, 28 Apr 2010 16:40:14 +0530 From: naya...@gmail.com To: gga...@apple.com CC: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Announcing WebKit2 Hi, What's the status of Webkit2? I've built the latest webkit version on Windows with --webkit2 option and I see that there is only one process shown in Task Manager irrespective of the number of Windows that I open. Reagrds, Nayan. On 4/13/10, Geoffrey Garen wrote: Will I be able to adjust process priorities to keep all processes of a certain MIME type (say application/x-shockwave-flash) to receive no more than 15% cpu time or monitor its memory usage? All process management is behind the API layer, the goal being to shield app developers from the details of process management. I'm not sure how you'd control the details of process management. This came up before in the context of security but resource allocation should be given some thought. I'm not always sure if the people who design web pages and serve thid party items care about the user's CPU. When we did java ads, this was a big deal but today it isn't hard to open a window or two and have all resources used doing stuff unrelated to browsing. Memory, CPU, and IO allocation should have some means for monitor if not control. Presonally I wouldn't mind a file in /etc/webkit to control this and other stuff. If you are making an alternative to IE, it may be helpful to remember all the things you don't like about IE and the importance of features in these other environments.. Geoff -- Regards, _Nayan_ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev _ The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multiaccountocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Wed, Apr 28, 2010 at 7:10 AM, Nayan naya...@gmail.com wrote: Hi, What's the status of Webkit2? I've built the latest webkit version on Windows with --webkit2 option and I see that there is only one process shown in Task Manager irrespective of the number of Windows that I open. Reagrds, Nayan. On Windows, the only way to build it right now is from within WebKit2.sln. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Apr 9, 2010, at 2:40 AM, Xan Lopez wrote: Another issue seems to be that parts of the public C API expose CoreFoundation, which definitely would be an issue for the other ports. I'm told on the side that this was just done as a quick solution to have something running and that if there's interest by other ports in using this we'd solve it with the good-old let's add another abstraction layer method, right? You can always use CFLite (available externally from Apple as 'opencflite' (http://sourceforge.net/projects/opencflite/). It builds on Linux, Windows, and Mac OS X. I've found it very useful for tracking the full Apple WebKit port, as it means there is much less code to duplicate and maintain. I can just let the kind folks at Apple do all the heavy lifting :-) -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Fri, Apr 9, 2010 at 2:33 AM, Adam Treat tr...@kde.org wrote: On Thursday 08 April 2010 09:24:32 pm Darin Adler wrote: On Apr 8, 2010, at 6:23 PM, Adam Treat wrote: Can someone please point to the bug report and the forum where this development was discussed by the greater WebKit community? The time for that discussion is now. The forum is here. I suggest we use this mailing list, not a bug report. Isn't that a little cart before the horse? It is already actively being landed... I'd have to agree. A new port is a maintenance burden on the entire community. Normally we discuss such things before starting to commit them. For example, my first question is whether we can adapt the Chromium WebKit API (or devise an API that could replace the Chromium WebKit API) since it sounds like our goals and the goals of this new API are fairly similar. If we do the former, I'm sure we can talk about changing the name. :-) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Fri, Apr 9, 2010 at 2:47 AM, Xan Lopez x...@gnome.org wrote: I suppose I could wait until you land the patches and see by myself, but: - In the wiki you mention that one goal of the new framework is to provide a stable C-based API. Is this meant as a public API for WebKit, the same in all platforms (like JSC), or a stable internal API for embedders to use in order to implement their native APIs on top? From some lines in the wiki (like WKView wrapping native objects) it seems like you want to do the former, but that seems like quite a massive effort and the loss of an important selling port of the various WebKit ports. - Does your new framework require any significant changes in WebCore? Could you briefly summarize them? - Do you see valid usecases in the long term for the traditional ports or are your plans to quickly transition all code to the new system as soon as it's ready? Another issue seems to be that parts of the public C API expose CoreFoundation, which definitely would be an issue for the other ports. I'm told on the side that this was just done as a quick solution to have something running and that if there's interest by other ports in using this we'd solve it with the good-old let's add another abstraction layer method, right? Xan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Apr 9, 2010, at 3:36 AM, Jeremy Orlow wrote: I hope this post clarifies why the Chromium WebKit port is not really a viable solution for our needs as it stands today. It was _very_ helpful. Thanks for taking the time to explain it so well. (It might be worth moving some of that description and diagrams into the Wiki as well.) Yeah, I'm trying to put some of this info in the wiki as we speak. :-) Anyhow, I sincerely do hope that we (Chromium + Apple) can both make it a goal to share as much code as possible between our two implementations, especially in WebCore. Maybe it'd even be useful and practical to upstream some Chromium code to WebKit to help further the WebKit2 API (and share more code)? It'll be great to talk about this stuff at the meeting next week. I hope so too! I'd love to discuss ideas along these lines, both in the meeting and by email. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
Hi! Your wiki says: DrawingArea - an abstraction for a cross-process drawing area. Multiple drawing strategies are possible, the simplest is just a shared memory bitmap. Could you tell me more about it? I am working on a parallel painting feature (GraphicsContext commands can be forwarded to different threads), and would be interested how this feature affect my work. Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
hi , why only multi-process and not multi-thread like android. It is useful for mobile environments. thanks, Zaheer On Fri, Apr 9, 2010 at 5:15 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 9, 2010, at 3:40 AM, Maciej Stachowiak wrote: On Apr 9, 2010, at 3:36 AM, Jeremy Orlow wrote: I hope this post clarifies why the Chromium WebKit port is not really a viable solution for our needs as it stands today. It was _very_ helpful. Thanks for taking the time to explain it so well. (It might be worth moving some of that description and diagrams into the Wiki as well.) Yeah, I'm trying to put some of this info in the wiki as we speak. :-) I made a bunch of updates to the wiki page: http://trac.webkit.org/wiki/WebKit2 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] Announcing WebKit2
Hi, It looks supporting multi-threaded model. See WebProcessLauncher.mm for detail. -- morita On Fri, Apr 9, 2010 at 9:11 PM, zaheer ahmad zaheer@gmail.com wrote: hi , why only multi-process and not multi-thread like android. It is useful for mobile environments. thanks, Zaheer On Fri, Apr 9, 2010 at 5:15 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 9, 2010, at 3:40 AM, Maciej Stachowiak wrote: On Apr 9, 2010, at 3:36 AM, Jeremy Orlow wrote: I hope this post clarifies why the Chromium WebKit port is not really a viable solution for our needs as it stands today. It was _very_ helpful. Thanks for taking the time to explain it so well. (It might be worth moving some of that description and diagrams into the Wiki as well.) Yeah, I'm trying to put some of this info in the wiki as we speak. :-) I made a bunch of updates to the wiki page: http://trac.webkit.org/wiki/WebKit2 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 -- morita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Friday 09 April 2010 06:24:51 am Maciej Stachowiak wrote: Given what proportion of overall maintenance work on WebKit I done by Apple, I don't think anyone is entitled to veto us adding a new API Whaa? Who is talking about veto of Apple's work? Rather, I am suggesting that it would have been helpful if people in the broader community had a chance to review and discuss the patches before they were summarily landed. To be clear, I have not had a chance to review the patches (I'm actually pretty excited by the ideas and I've no doubt the work is technically excellent given the people involved) and see what is going on before they were pushed into the tree. It just would have been nice to give the *community* more of a heads up and a chance to have a look and offer opinions. This isn't about 'Apple' and 'veto' so much as it is about a significant new piece of tech being added to WebKit without going through the common procedure where a bug is opened a patch is attached webkit-dev is notified and people have a chance to discuss and poke a little. It just felt a little rushed especially so that the new stuff is being landed with style errors. I normally wouldn't quibble with style issues, but others have and new ports have been required to fix any and all styling issues before landing. layer. I also recall that when the Chromium API layer was added, no one asked permission, you just let us know that it was coming. Which is fine - API layers are pretty low cost, and I hope no one would argue against a major contributor including theirs. What's more, this is really a parallel version of existing well-maintained API layers. I do not like the implication that Apple should have to ask permission for what we do with the WebKit API on Mac OS X. We do not ask the Qt or Gtk developers to explain all their API choices. Again, I think it'd be good to get away from 'Apple' vs 'Others'. The community as a whole has some fairly common procedures for landing large changes like this. This just felt a bit rushed. And no doubt I was a bit taken by the name 'WebKit2'. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
Another issue seems to be that parts of the public C API expose CoreFoundation, which definitely would be an issue for the other ports. I'm told on the side that this was just done as a quick solution to have something running and that if there's interest by other ports in using this we'd solve it with the good-old let's add another abstraction layer method, right? I had some involvement in that decision, so I'll take a crack at answering this. We want to avoid adding, at the API layer, new abstractions for basic types like strings, URLRequests, URLResponses, etc -- for two reasons: 1. That would require a lot of unnecessary and error-prone typing -- both for WebKit implementors and for WebKit clients. 2. That would require wasting memory and CPU to make copies at API boundaries. Hopefully, a given port can use the same port-specific types at the API layer as it uses inside WebCore. Our theory is that, on any given platform, those are the best/easiest types for the WebKit client to use, anyway. For example, an application should be able to pass WebKit a platform-specific URLRequest, and WebKit should be able to pass that to WebCore in turn, and WebCore should be able to pass that to its networking layer in turn -- all without any copying or conversion code. For CF ports, that's a CFURLRequest. For Qt, a QNetworkRequest. Etc. I think the right way to achieve this will be with a simple typedef, but we won't know for sure until more ports try to adopt this API. Best, Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Apr 8, 2010, at 5:58 PM, Maciej Stachowiak wrote: - Does your new framework require any significant changes in WebCore? Could you briefly summarize them? No WebCore changes are required - it works with the existing WebCore. Right now WebCore needs to be built with some different flags (ENABLE_EXPERIMENTAL_SINGLE_VIEW_MODE=1 and WTF_USE_WEB_THREAD=1), but the goal is that the same WebCore should be able to support both WebKit and WebKit2 (and on the mac, both WebKit frameworks will link against the same WebCore framework). - Anders ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Apr 9, 2010, at 7:14 AM, Adam Treat wrote: On Friday 09 April 2010 06:24:51 am Maciej Stachowiak wrote: Given what proportion of overall maintenance work on WebKit I done by Apple, I don't think anyone is entitled to veto us adding a new API Whaa? Who is talking about veto of Apple's work? Rather, I am suggesting that it would have been helpful if people in the broader community had a chance to review and discuss the patches before they were summarily landed. To be clear, I have not had a chance to review the patches (I'm actually pretty excited by the ideas and I've no doubt the work is technically excellent given the people involved) and see what is going on before they were pushed into the tree. It just would have been nice to give the *community* more of a heads up and a chance to have a look and offer opinions. This isn't about 'Apple' and 'veto' so much as it is about a significant new piece of tech being added to WebKit without going through the common procedure where a bug is opened a patch is attached webkit-dev is notified and people have a chance to discuss and poke a little. There were in fact bugs opened with patches attached, and webkit-dev was notified before any of the patches were committed afaik. However, the new piece of tech really is just a new API layer for the Mac and Win ports. We are interested in other people being able to reuse this technology, but fundamentally, this is an extension of our existing APIs. It just felt a little rushed especially so that the new stuff is being landed with style errors. I normally wouldn't quibble with style issues, but others have and new ports have been required to fix any and all styling issues before landing. Agree, it was not good to commit with style errors and we should try to fix them promptly. layer. I also recall that when the Chromium API layer was added, no one asked permission, you just let us know that it was coming. Which is fine - API layers are pretty low cost, and I hope no one would argue against a major contributor including theirs. What's more, this is really a parallel version of existing well-maintained API layers. I do not like the implication that Apple should have to ask permission for what we do with the WebKit API on Mac OS X. We do not ask the Qt or Gtk developers to explain all their API choices. Again, I think it'd be good to get away from 'Apple' vs 'Others'. The community as a whole has some fairly common procedures for landing large changes like this. This just felt a bit rushed. And no doubt I was a bit taken by the name 'WebKit2'. It was in retrospect not a good choice of name. We hoped it would be a very boring choice. Think of it as WebKit/mac/async/ or something and see if you might feel differently. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Apr 9, 2010, at 2:34 AM, Jeremy Orlow wrote: On Fri, Apr 9, 2010 at 2:33 AM, Adam Treat tr...@kde.org wrote: On Thursday 08 April 2010 09:24:32 pm Darin Adler wrote: On Apr 8, 2010, at 6:23 PM, Adam Treat wrote: Can someone please point to the bug report and the forum where this development was discussed by the greater WebKit community? The time for that discussion is now. The forum is here. I suggest we use this mailing list, not a bug report. Isn't that a little cart before the horse? It is already actively being landed... I'd have to agree. A new port is a maintenance burden on the entire community. Normally we discuss such things before starting to commit them. We seem to welcome pretty much any port that has an active maintainer. In the past we have accepted the Chromium port despite it having a new JS engine, new DOM bindings, an overreaching catch-all #ifdef for unrelated changes, numerous layering violations, and seemingly unnecessary changes or replacements of platform-independent code. All of these problems were discussed on webkit-dev and in Bugzilla prior to Chromium landing, but they were largely ignored and still exist today. For example, my first question is whether we can adapt the Chromium WebKit API (or devise an API that could replace the Chromium WebKit API) since it sounds like our goals and the goals of this new API are fairly similar. If we do the former, I'm sure we can talk about changing the name. :-) As it stands, there is no way for a WebKit port to opt in to Chromium's multiprocess model, and making this possible has never been a priority for the Chromium team. WebKit 2 looks a lot cleaner in this respect. Cameron___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Fri, Apr 9, 2010 at 1:53 PM, Cameron Zwarich cwzwar...@webkit.org wrote: We seem to welcome pretty much any port that has an active maintainer. IMHO, that's a good thing. I wonder if we should archive ports that don't have an active maintainer (e.g., by moving them into a branch). Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
Which ports are considered unmaintained? Kenneth On Fri, Apr 9, 2010 at 6:03 PM, Adam Barth aba...@webkit.org wrote: On Fri, Apr 9, 2010 at 1:53 PM, Cameron Zwarich cwzwar...@webkit.org wrote: We seem to welcome pretty much any port that has an active maintainer. IMHO, that's a good thing. I wonder if we should archive ports that don't have an active maintainer (e.g., by moving them into a branch). Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Kenneth Rohde Christiansen Technical Lead / Senior Software Engineer Qt Labs Americas, Nokia Technology Institute, INdT Phone +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Apr 9, 2010, at 2:03 PM, Adam Barth wrote: On Fri, Apr 9, 2010 at 1:53 PM, Cameron Zwarich cwzwar...@webkit.org wrote: We seem to welcome pretty much any port that has an active maintainer. IMHO, that's a good thing. I wonder if we should archive ports that don't have an active maintainer (e.g., by moving them into a branch). I think that would be good, if there are any such ports (I am not sure there are any on trunk currently that are totally unmaintained). Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Apr 9, 2010, at 2:09 PM, Maciej Stachowiak wrote: On Apr 9, 2010, at 2:03 PM, Adam Barth wrote: On Fri, Apr 9, 2010 at 1:53 PM, Cameron Zwarich cwzwar...@webkit.org wrote: We seem to welcome pretty much any port that has an active maintainer. IMHO, that's a good thing. I wonder if we should archive ports that don't have an active maintainer (e.g., by moving them into a branch). I think that would be good, if there are any such ports (I am not sure there are any on trunk currently that are totally unmaintained). S60? http://trac.webkit.org/browser/S60 --Oliver 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] Announcing WebKit2
On Friday 09 April 2010 02:11:33 pm Maciej Stachowiak wrote: There were in fact bugs opened with patches attached, and webkit-dev was notified before any of the patches were committed afaik. However, Indeed, but the post to webkit-dev had no link to the patches and no time was given for anyone in the community who hadn't been privy to the private development to have a look before it was landed. the new piece of tech really is just a new API layer for the Mac and Win ports. We are interested in other people being able to reuse this technology, but fundamentally, this is an extension of our existing APIs. I understand this now. I definitely didn't get this impression at first, but probably my mistake. It was in retrospect not a good choice of name. We hoped it would be a very boring choice. Think of it as WebKit/mac/async/ or something and see if you might feel differently. It does throw things in a different light. However, I still think it would have been nice to give people an opportunity to have a look and a little time for discussion before it was landed. I lament that we have so much private development in the community although I understand the necessity at times. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Friday 09 April 2010 04:53:31 pm Cameron Zwarich wrote: In the past we have accepted the Chromium port despite it having a new JS engine, new DOM bindings, an overreaching catch-all #ifdef for unrelated changes, numerous layering violations, and seemingly unnecessary changes or replacements of platform-independent code. All of these problems were discussed on webkit-dev and in Bugzilla prior to Chromium landing, but they were largely ignored and still exist today. In the past we've also had new ports land with some fairly hefty requirements including fixing of all style violations, layering violations, and generally going through the code with a fine tooth comb. Were that all ports and contributions received the same treatment. Cheers, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Fri, Apr 9, 2010 at 2:36 PM, Darin Fisher da...@chromium.org wrote: On Fri, Apr 9, 2010 at 1:53 PM, Cameron Zwarich cwzwar...@webkit.orgwrote: On Apr 9, 2010, at 2:34 AM, Jeremy Orlow wrote: On Fri, Apr 9, 2010 at 2:33 AM, Adam Treat tr...@kde.org wrote: On Thursday 08 April 2010 09:24:32 pm Darin Adler wrote: On Apr 8, 2010, at 6:23 PM, Adam Treat wrote: Can someone please point to the bug report and the forum where this development was discussed by the greater WebKit community? The time for that discussion is now. The forum is here. I suggest we use this mailing list, not a bug report. Isn't that a little cart before the horse? It is already actively being landed... I'd have to agree. A new port is a maintenance burden on the entire community. Normally we discuss such things before starting to commit them. We seem to welcome pretty much any port that has an active maintainer. In the past we have accepted the Chromium port despite it having a new JS engine, new DOM bindings, an overreaching catch-all #ifdef for unrelated changes, numerous layering violations, and seemingly unnecessary changes or replacements of platform-independent code. All of these problems were discussed on webkit-dev and in Bugzilla prior to Chromium landing, but they were largely ignored and still exist today. Perhaps we should discuss some of these problems that you perceive to still exist with the Chromium port at the WebKit conference. I'd like to understand better. I have heard/read some arguments in favor of breaking PLATFORM(CHROMIUM) up into separate defines, and that all sounds conceptually reasonable, but there hasn't been much of a need to do so since there have been no other ports interested in sharing portions of what is currently behind PLATFORM(CHROMIUM). Perhaps we're at a point now, because of WebKit2, in which we would benefit from sharing code that is presently behind PLATFORM(CHROMIUM)? Regards, -Darin For example, Sam mentioned that WebKit2 might want to use the BackForwardListClient that we added for the Chromium port. It seems like a trivial change to invent an ENABLE option for that so that it can be shared. Are there more examples? -Darin For example, my first question is whether we can adapt the Chromium WebKit API (or devise an API that could replace the Chromium WebKit API) since it sounds like our goals and the goals of this new API are fairly similar. If we do the former, I'm sure we can talk about changing the name. :-) As it stands, there is no way for a WebKit port to opt in to Chromium's multiprocess model, and making this possible has never been a priority for the Chromium team. WebKit 2 looks a lot cleaner in this respect. Cameron ___ 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] Announcing WebKit2
On Apr 9, 2010, at 2:13 PM, Adam Treat wrote: On Friday 09 April 2010 02:11:33 pm Maciej Stachowiak wrote: the new piece of tech really is just a new API layer for the Mac and Win ports. We are interested in other people being able to reuse this technology, but fundamentally, this is an extension of our existing APIs. I understand this now. I definitely didn't get this impression at first, but probably my mistake. I think it was initially our mistake in communicating poorly. I apologize for that, we could have done a better job of making the scope of the work clear. We also didn't have to rush quite so much to commit the patches - we were just eager to share this code for broader review and input quicly. It was in retrospect not a good choice of name. We hoped it would be a very boring choice. Think of it as WebKit/mac/async/ or something and see if you might feel differently. It does throw things in a different light. However, I still think it would have been nice to give people an opportunity to have a look and a little time for discussion before it was landed. I lament that we have so much private development in the community although I understand the necessity at times. Really our goal here was to have something sufficiently working that it was worth showing. This project is in no way locked in or imminently shipping - it is an early technology preview. We would *love* to have feedback from you and other community members. Even though the driving force is to be a new API layer for Apple's ports, we are very interested in making the code useful for other ports if they are interested. One thing we're looking at is how to make the API more agnostic about basic types like strings, since at least some Gtk folks have expressed interest in the basic technology. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Thu, Apr 8, 2010 at 3:01 PM, Anders Carlsson ander...@apple.com wrote: Hello everyone, This is a heads-up that we will shortly start landing patches for a new WebKit framework that we at Apple have been working on for a while. We currently call this new framework WebKit2. WebKit2 is designed from the ground up to support a split process model, where the web content (JavaScript, HTML, layout, etc) lives in a separate process. This model is similar to what Google Chrome offers, with the major difference being that we have built the process split model directly into the framework, allowing other clients to use it. Some high-level documentation is available at http://trac.webkit.org/wiki/WebKit2 Currently WebKit2 is available for Mac and Windows, and we would gladly accept patches to add more ports. We're more than happy to answer any questions you might have, and we hope that this will be a topic of discussion at the WebKit Contributors Meeting. Please, please consider making every call non-block, particularly those that requires interaction with user, avoiding nested main loops and bugs that come from these[1]. For instance, these could call user that is later responsible to call another function, providing the continuation based on some shared token/context. [1] https://lists.webkit.org/pipermail/webkit-dev/2010-March/011845.html -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Thu, Apr 8, 2010 at 4:25 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Thu, Apr 8, 2010 at 3:01 PM, Anders Carlsson ander...@apple.com wrote: Hello everyone, This is a heads-up that we will shortly start landing patches for a new WebKit framework that we at Apple have been working on for a while. We currently call this new framework WebKit2. WebKit2 is designed from the ground up to support a split process model, where the web content (JavaScript, HTML, layout, etc) lives in a separate process. This model is similar to what Google Chrome offers, with the major difference being that we have built the process split model directly into the framework, allowing other clients to use it. Some high-level documentation is available at http://trac.webkit.org/wiki/WebKit2 Currently WebKit2 is available for Mac and Windows, and we would gladly accept patches to add more ports. We're more than happy to answer any questions you might have, and we hope that this will be a topic of discussion at the WebKit Contributors Meeting. Please, please consider making every call non-block, particularly those that requires interaction with user, avoiding nested main loops and bugs that come from these[1]. For instance, these could call user that is later responsible to call another function, providing the continuation based on some shared token/context. As noted in the linked Wiki document, the intent is to create a completely non-blocking API. That is one of our biggest motivations in pursuing this project. - Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Fri, Apr 9, 2010 at 1:01 AM, Anders Carlsson ander...@apple.com wrote: Hello everyone, This is a heads-up that we will shortly start landing patches for a new WebKit framework that we at Apple have been working on for a while. We currently call this new framework WebKit2. WebKit2 is designed from the ground up to support a split process model, where the web content (JavaScript, HTML, layout, etc) lives in a separate process. This model is similar to what Google Chrome offers, with the major difference being that we have built the process split model directly into the framework, allowing other clients to use it. Some high-level documentation is available at http://trac.webkit.org/wiki/WebKit2 Currently WebKit2 is available for Mac and Windows, and we would gladly accept patches to add more ports. We're more than happy to answer any questions you might have, and we hope that this will be a topic of discussion at the WebKit Contributors Meeting. I suppose I could wait until you land the patches and see by myself, but: - In the wiki you mention that one goal of the new framework is to provide a stable C-based API. Is this meant as a public API for WebKit, the same in all platforms (like JSC), or a stable internal API for embedders to use in order to implement their native APIs on top? From some lines in the wiki (like WKView wrapping native objects) it seems like you want to do the former, but that seems like quite a massive effort and the loss of an important selling port of the various WebKit ports. - Does your new framework require any significant changes in WebCore? Could you briefly summarize them? - Do you see valid usecases in the long term for the traditional ports or are your plans to quickly transition all code to the new system as soon as it's ready? Cheers, Xan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Apr 8, 2010, at 5:47 PM, Xan Lopez wrote: - In the wiki you mention that one goal of the new framework is to provide a stable C-based API. Is this meant as a public API for WebKit, the same in all platforms (like JSC), or a stable internal API for embedders to use in order to implement their native APIs on top? From some lines in the wiki (like WKView wrapping native objects) it seems like you want to do the former, but that seems like quite a massive effort and the loss of an important selling port of the various WebKit ports. As I understand it, the goal is to have a C API that is suitable and works well cross platform for all the many platform independent operations; it is indeed analogous the one for JavaScriptCore in that respect. When you refer to a “selling point” of WebKit ports, I assume you are referring to how those ports integrate with the surrounding OS and frameworks. For example, the Mac OS X port provides an Objective-C API that fits in well with the rest of Cocoa. The goal would be that such API can be cleanly built on top of the C-based API and should offer a simple way to “drop down” to the platform independent C one and vice versa. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Apr 8, 2010, at 5:47 PM, Xan Lopez wrote: I suppose I could wait until you land the patches and see by myself, but: - In the wiki you mention that one goal of the new framework is to provide a stable C-based API. Is this meant as a public API for WebKit, the same in all platforms (like JSC), or a stable internal API for embedders to use in order to implement their native APIs on top? From some lines in the wiki (like WKView wrapping native objects) it seems like you want to do the former, but that seems like quite a massive effort and the loss of an important selling port of the various WebKit ports. It will be available as a public API, but as Darin explained, it's up to individual ports whether to wrap this API, expose it directly, or do some combination. For the Mac OS X API, we will be doing a combination. - Does your new framework require any significant changes in WebCore? Could you briefly summarize them? No WebCore changes are required - it works with the existing WebCore. - Do you see valid usecases in the long term for the traditional ports or are your plans to quickly transition all code to the new system as soon as it's ready? I think that would be up to the individual ports. We expect that on Mac OS X, we will have to support the classic WebKit API for a long time, perhaps indefinitely, in parallel with the new WebKit2-based API. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
On Fri, Apr 9, 2010 at 2:52 AM, Darin Adler da...@apple.com wrote: As I understand it, the goal is to have a C API that is suitable and works well cross platform for all the many platform independent operations; it is indeed analogous the one for JavaScriptCore in that respect. When you refer to a “selling point” of WebKit ports, I assume you are referring to how those ports integrate with the surrounding OS and frameworks. For example, the Mac OS X port provides an Objective-C API that fits in well with the rest of Cocoa. The goal would be that such API can be cleanly built on top of the C-based API and should offer a simple way to “drop down” to the platform independent C one and vice versa. I see, so the answer is both, kinda. Interesting. Having a stable API for embedders to use to build their native APIs on top would certainly ease the lives of port maintainers, and using those stable APIs in the situations where it makes sense to use them can certainly be a good idea. Interesting choices for all of us ahead :) Xan -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
If its in a separate process, does Accessibility still work as expected? On Apr 8, 2010, at 4:01 PM, Anders Carlsson wrote: Hello everyone, This is a heads-up that we will shortly start landing patches for a new WebKit framework that we at Apple have been working on for a while. We currently call this new framework WebKit2. WebKit2 is designed from the ground up to support a split process model, where the web content (JavaScript, HTML, layout, etc) lives in a separate process. This model is similar to what Google Chrome offers, with the major difference being that we have built the process split model directly into the framework, allowing other clients to use it. Some high-level documentation is available at http://trac.webkit.org/wiki/WebKit2 Currently WebKit2 is available for Mac and Windows, and we would gladly accept patches to add more ports. We're more than happy to answer any questions you might have, and we hope that this will be a topic of discussion at the WebKit Contributors Meeting. Thanks, Anders Carlsson and Sam Weinig. ___ 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] Announcing WebKit2
Hi, Can someone please point to the bug report and the forum where this development was discussed by the greater WebKit community? Cheers, Adam On Thursday 08 April 2010 08:58:22 pm Maciej Stachowiak wrote: On Apr 8, 2010, at 5:47 PM, Xan Lopez wrote: I suppose I could wait until you land the patches and see by myself, but: - In the wiki you mention that one goal of the new framework is to provide a stable C-based API. Is this meant as a public API for WebKit, the same in all platforms (like JSC), or a stable internal API for embedders to use in order to implement their native APIs on top? From some lines in the wiki (like WKView wrapping native objects) it seems like you want to do the former, but that seems like quite a massive effort and the loss of an important selling port of the various WebKit ports. It will be available as a public API, but as Darin explained, it's up to individual ports whether to wrap this API, expose it directly, or do some combination. For the Mac OS X API, we will be doing a combination. - Does your new framework require any significant changes in WebCore? Could you briefly summarize them? No WebCore changes are required - it works with the existing WebCore. - Do you see valid usecases in the long term for the traditional ports or are your plans to quickly transition all code to the new system as soon as it's ready? I think that would be up to the individual ports. We expect that on Mac OS X, we will have to support the classic WebKit API for a long time, perhaps indefinitely, in parallel with the new WebKit2-based API. 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] Announcing WebKit2
On Apr 8, 2010, at 6:19 PM, Chris Fleizach wrote: If its in a separate process, does Accessibility still work as expected? It does not yet work in this rough initial version, but it's certainly our intent to make it work. Cheers, Maciej On Apr 8, 2010, at 4:01 PM, Anders Carlsson wrote: Hello everyone, This is a heads-up that we will shortly start landing patches for a new WebKit framework that we at Apple have been working on for a while. We currently call this new framework WebKit2. WebKit2 is designed from the ground up to support a split process model, where the web content (JavaScript, HTML, layout, etc) lives in a separate process. This model is similar to what Google Chrome offers, with the major difference being that we have built the process split model directly into the framework, allowing other clients to use it. Some high-level documentation is available at http://trac.webkit.org/wiki/WebKit2 Currently WebKit2 is available for Mac and Windows, and we would gladly accept patches to add more ports. We're more than happy to answer any questions you might have, and we hope that this will be a topic of discussion at the WebKit Contributors Meeting. Thanks, Anders Carlsson and Sam Weinig. ___ 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] Announcing WebKit2
Great. I think Google chrome has taken a similar approach and have had trouble making accessibility work because of the inter-process separation, so when we come up with a solution, maybe they can adopt as well. On Apr 8, 2010, at 6:30 PM, Maciej Stachowiak wrote: On Apr 8, 2010, at 6:19 PM, Chris Fleizach wrote: If its in a separate process, does Accessibility still work as expected? It does not yet work in this rough initial version, but it's certainly our intent to make it work. Cheers, Maciej On Apr 8, 2010, at 4:01 PM, Anders Carlsson wrote: Hello everyone, This is a heads-up that we will shortly start landing patches for a new WebKit framework that we at Apple have been working on for a while. We currently call this new framework WebKit2. WebKit2 is designed from the ground up to support a split process model, where the web content (JavaScript, HTML, layout, etc) lives in a separate process. This model is similar to what Google Chrome offers, with the major difference being that we have built the process split model directly into the framework, allowing other clients to use it. Some high-level documentation is available at http://trac.webkit.org/wiki/WebKit2 Currently WebKit2 is available for Mac and Windows, and we would gladly accept patches to add more ports. We're more than happy to answer any questions you might have, and we hope that this will be a topic of discussion at the WebKit Contributors Meeting. Thanks, Anders Carlsson and Sam Weinig. ___ 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] Announcing WebKit2
On Thursday 08 April 2010 09:24:32 pm Darin Adler wrote: On Apr 8, 2010, at 6:23 PM, Adam Treat wrote: Can someone please point to the bug report and the forum where this development was discussed by the greater WebKit community? The time for that discussion is now. The forum is here. I suggest we use this mailing list, not a bug report. Isn't that a little cart before the horse? It is already actively being landed... Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Announcing WebKit2
Hi, On Apr 8, 2010, at 4:01 PM, Anders Carlsson wrote: Hello everyone, This is a heads-up that we will shortly start landing patches for a new WebKit framework that we at Apple have been working on for a while. We currently call this new framework WebKit2. Awesome! I can't wait to see the patches. Is there a top-level bug I can subscribe to to keep track? -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
