Robert Norris Web Browser Interview


When do you plan to announce the name?
Right here, right now! The browser will be called "Traveller" (that's British spelling, with two ells). I had already thought of this as a potential name before asking for ideas, and when a couple of people suggested it too I knew it was good.

The reasons I like it are threefold:
- Its a good companion for Wanderer.
- It carries on the tradition of giving browsers a name related to finding the unknown: Navigator, Explorer, Konqueror, Safari, etc.
- It references an in-joke among the members of my team at work, so its just a little bit personal too.

Have you been surprised about the response you have received on naming the new web browser?
I confess that part of the reason for asking for name ideas was to drum up a little hype, but the response was totally unexpected. People poured from the woodwork to offer an opinion, and I notice the big Amiga sites also linked, which was weird - I've never really considered myself to be any kind of Amiga person. Maybe I am, just a little bit :)

Do you have a master plan on the creation of this new browser yet or are you mainly concentrating on the bounty requirements right now?
I've split the work into two stages. The first is the port of WebKit. This requires porting the two WebKit components, JavaScriptCore and WebCore, and writing a minimal "launcher" application that basically brings up single browser window so the engine can be tested. This stage also requires porting the various libraries that WebKit depends on and filling gaps in AROS itself.

The second stage is integration of the engine in AROS itself. This involves creating a Zune widget that wraps WebKit, and will allow any Zune application to use the engine if it chooses. Finally, the development of Traveller proper, the Zune-based browser, can begin.

Do you plan to add things like tabs or bookmarks?
Not initially. My goal for completion of the bounty is for just a basic browser UI: location bar and forward, back, stop and home buttons. Features like tabs, bookmarks and whatever else can be added later.

I don't yet know whether it will be me doing this or someone else. My hope is that by this point there will be others interested in working on Traveller. I really don't want to be doing web browsers forever! There's too many other things in AROS that need work and I tend to get bored if I do the same thing for too long :)

How did you decide WebKit was the way to go to bring a web browser engine to AROS?
A big part of my programming experience has been web programming, so I know that the web is an incredibly complicated place, and that it takes a serious amount of code to make a browser that can handle even a small amount of it reliably.

The web is also well known for issues with browser compatibility. We're all familiar with the experience of a website that doesn't work in our browser of choice.

Both of these factors mean that when writing a browser for a niche platform like AROS, where you don't have the resources to properly develop and maintain that much code, you really want from an established browser that has a large enough share of the market that they will take care of the complexities of the web so you don't have to.

Once I'd decided that, its was pretty much a case of looking at what kinds of free browser code exists and what I could use. For a long time there's pretty much only been one game in town, and that is of course Gecko, the engine that powers Firefox. Its been a while since I've looked at the code, but I remember it being nearly impossible to penetrate, let alone modify. I haven't paid much attention to it more recently, but I hear that not much as changed. Also, the authors are
more and more focused on Firefox these days, so its difficult to find support for porting work.

WebKit is a newer project (though it has its roots in KJS and KHTML, the components that drive KDE's Konqueror browser), so you could argue that support for it from websites isn't as widespread, but Apple have nearly done everything right with it. They've kept the source open, actively encouraged contributions from anyone and worked hard to keep it small, fast and portable. This has paid off; WebKit of course drives the Safari browser on OS X (and lately Windows), but also has a large part of the mobile market, pushed by Nokia. Then came the iPhone, and we see websites clamouring to make their sites compatible with it. Google has just announced their phone project, Android, which also uses WebKit.

So what we have here is a browser engine that just wants to be ported to everything getting better and better support for the web at large, from both sides. To me it was the obvious choice.

Since WebKit is ported over to AROS now, what is left to do to make it a web browser that we can actually use? More specifically, what is the difference between having a web browser engine and having a web browser?
Well first, WebKit isn't ported yet - I've really only just begun. The Javascript engine works, but the web engine will take a lot more work.

The best way to look at what an browser engine does is to look at your existing browser. There's all the outside stuff - menus, forward/back/home buttons, location bar, tabs, bookmarks, status bar, etc, and then there's the main part of the window where the webpages themselves appear. WebKit (or Gecko or whatever) is responsible for the webpage bit. All the outer stuff that makes the engine into a proper browser is known as "chrome", and its chief concern is with integrating the engine with the rest of the desktop.

This "chrome" is what's needed to turn WebKit into a browser. That's what Traveller really is.

Is this much easier than writing a web browser from scratch?
Absolutely. Although getting WebKit to use AROS libraries and such to do it's display and input is difficult, its childs play compared to the horror of developing all the web stuff.

I've noticed people asking if they can have FireFox on AROS now that WebKit is there. But FireFox doesn't use the WebKit engine, it uses Gecko. The Mac web browser Safari uses WebKit. Do you agree? What are your thoughts on this?
You're correct. Firefox has nothing to do with WebKit, and porting WebKit won't aid a port of Firefox (except perhaps in the case of places where I've had to improve the AROS C library, or update our compilers, etc, which a Firefox port could potentially make use of).

To be honest, I don't see much value in porting Firefox to AROS. It might be worth porting Gecko (though I doubt we're big enough for both of them), but Firefox would suck - it looks nothing like an AROS app.

How do you think this new AROS browser will compare to other web browsers on Amiga and MorphOS. For instance, Sputnik, the KHTML based browser that was ported to MorphOS? IBrowse or AWeb that is available for the Amiga?
I haven't used any of those browsers, only read about them and seen screenshots, so I may be a long way off (and I expect to be politely corrected in that case), but as far as I can tell the Traveller will compare very favourably.

IBrowse and AWeb seem to be too far behind in their support of modern web features to really be relevant. As I've said previously, I don't see the point of web browsers that can't work with the big, Javascript-heavy sites out there. I'm talking about GMail here :)

As for Sputnik, its actually based on S60 WebKit, which is a fork of WebKit done by Nokia for their mobile phones. I suppose Traveller will be most similar to that, but as far as I've seen the S60 branch isn't being kept up to date with the new developments going into WebKit. That may mean that the Traveller is able to get new features faster.

What kind of challenges do you face with this project?
There's two major things that have made and will continue to make this project difficult.

The first is shortcomings and bugs in AROS facilities. For example, porting JavaScriptCore required a system call called posix_memalign(), which allocates memory in a different way than usual. AROS didn't have it, so I had to research both how the call works and how AROS does memory allocation before I could implement it. JavaScriptCore also required some functions that our system math library didn't have. To get them I ended up having to update the math library from its source (FreeBSD). This took a week as so much in it had changed. Now I'm struggling with our network libraries because they're not fully integrated into the core which makes them a little difficult to work with.

These sort of things are usually time consuming to fix, but worth doing because the whole of AROS benefits from them.

The other challenge is the WebCore porting work itself. Its going to take a lot to hook it up to AROS, because of all the work it needs to do. It needs to draw things to the screen, accept input, render fonts and images, etc. I know some parts of this stuff on the AROS side, but others not at all, so I'll have to learn about them. Also, I'm told that there's quite a bit of stuff to implement on the WebCore side that needs to be done to even get minimal functionality - something like 70 files. I haven't even looked into this properly, but I know its not going to be easy, even if AROS provided everything I need and my C++ knowledge was perfect rather than practically nonexistant.

Learning new things is the whole reason that I spend so much of my recreational time on computers, so none of this is a problem. It all just takes time.

I read in your blog about the JavaScriptCore engine inside WebKit. Did you have to do anything special to support JavaScript when porting? Were you able to compile it using gcc or how was that handled?
JavaScriptCore is a Javascript interpreter - it runs Javascript code. It doesn't need Javascript to compile though; its written in plain C++.

The porting process has been interesting. First, I needed a compiler. WebKit has to be compiled with GCC version 4, and of course is written in C++. We had patches for GCC to make it build programs for AROS, but the last version that had C++ support was version 3. We had a version 4 patch, but that was only for C, not C++. So the first thing I did was to take a fresh copy of the latest GCC (4.2.2), and get C++ working.

Once I had a compiler, I modified the WebKit build system to use it, and started it up. Every time the build failed I fixed the problem and tried again. Some of those things required adding small amounts of code to WebKit to help it know what it should do on AROS. Other things required changes to AROS, for example, the math library stuff mentioned above.

Eventually, the build completed and produced the JavaScriptCore test program, testkjs. I moved this and the Javascript test suite into my AROS install, fired it up and started running the tests.

The test program was reporting some unusual problems, so then I had to go back to the code and change small things. The folks in the #webkit IRC channel helped a huge amount here, teaching me how various aspects of the code works.

Thats pretty much the process for porting any applicaton or library, by the way. Teach the build system for the project how to use AROS compilers, hack at the code until it builds, then test and fix the bugs.

This is a very exciting project! I am extremely excited about it! I am glad you decided to work on this project and I wish you the best of luck!
Thanks! I'm pretty excited too! And thanks for the interesting questions, they really helped me make sure I know exactly what I'm trying to do here :)

Cheers,
Rob.
*** Click here for Rob's Blog ***