A lot of exciting things are happening in the world of web browsers these days. Google's Chrome has shaken things up a bit while Firefox, Safari and Opera all continue to improve (more or less) and we now have at least three very fast open source Javascript engines (JavascriptCore Extreme, V8 and TraceMonkey.) IE is even starting to suck less. I consider a solid web browser as my primary need on any operating system. Haiku has our Firefox port, but it is not up to the standards many of us want, including those who ported it, who are under constraints imposed by the Mozilla project. While Firefox 3 offers some improvements, I find it is starting to feel bloated, slow and buggy and is not the Firefox browser I fell in love with. Therefore I am not even sure it is worth porting. As many of you may recall, I ported WebKit to Haiku more than a year ago. With the help of Andrea Anzani and Stephan Assmus we got it to render some pages, but a lot of functionality was still missing. Everyone stopped working on it and that code has languished for the last year as WebKit has changed and improved in countless ways. Haiku has also continued to be improved and now we even have a native GCC4 tool chain, so there is no longer a need to cross compile when working on ports like WebKit. What this means to me is that it is time the WebKit port is brought up-to-date and finally committed into the official WebKit repository. I also think we should write a native web browser to use this WebKit port. But both of these are big projects and I am crazy to think I could do it alone. Plus several people have shown interest in helping out on this, but I have repeatedly told them "please wait until I can do x,y,z." Well I have realized I am slowing things down too much and need to let other people help. So, I ask: who wants to help on this? I mean REALLY, who has the time, motivation and tenacity to work on this? To give an idea, here is what I think needs to get done: 1. The latest WebKit code needs to be "re-ported" to compile again for Haiku. This doesn't mean that everything works, but that the build system is set up right again. A LOT has changed in a year (especially in JavaScriptCore) so this might take a little while. My idea for this was to just start with a fresh checkout of WebKit, and then bring over whatever is needed from my original port. *IMPORTANT* For those who don't know, my ported code can be checked out anonymously from here: http://ryanleavengood.com/svn/repo/WebKit/trunk/ It has been there ever since I wrote it, so it isn't like I was trying to hide it from anyone. Still no one worked on it once Andrea stopped in January 2008. It will probably still even compile. 2. A decision needs to be made whether we continue to use Jam as the build tool for the WebKit port, or try to use one of the existing WebKit build systems. Within the last year a new autotools based build has been added, which might be a better choice, mainly because other people would maintain it. Jam is nice because it can easily snap into a Haiku build directory. But then have to maintain that when things are moved around plus not all WebKit developers on Haiku will necessarily also be Haiku developers with the full tree checked out. At the same time I am not 100% sure whether the autotools build system in WebKit can work on Haiku. This should be determined first. For number 1 above it might be easiest just to update the jam build system I created for WebKit and then figure out whether autotools would work too. 3. Once the above is done a lot of the missing pieces in the WebKit port should be filled in. The thread model needs to be improved and various things like Affine transform code need to be added. 4. Probably while the above is being done a browser shell should be started. Maybe some of the existing BeOS open source browsers could serve as a starting point, though I at least am open to starting from scratch. And before anyone mentions it, I too like Chrome but the Chromium code that Chrome is built on is A LOT OF CODE and would probably be just as hard to port as WebKit. So for now I think we should make use of some pieces of it (like the "omnibar" code), but save a full port for later, if ever. I would not be opposed to copying the Chrome interface though... 5. At some point a decently working WebKit port and browser shell should be available and people can start testing. Then it is the usual add features/bugs, test, release, rinse and repeat. Once the grunt work (1-3) is over though, this should be quite fun and I would hope new developers would be able to come aboard just as easily as they do on Haiku. So, after hearing all that, who wants to help? :) Let me know, Ryan