Monthly Archives: March 2008

Ten Years

Posted on by
Reply

Ten years ago Netscape released the source code to their browser. They called it Mozilla, I downloaded and built it at my work at the time. I didn’t manage to build it immediately, but I worked it out in the end.

Somehow I’ve spent most of the past seven years working with the platform. I touched on it at Eazel where we used Gecko to display HTML, but mostly left the hard work of integrating a barely-ready gtkmozembed to Mike and Ramiro

Then at Danger I ended up as the main engineer working on our licensed fork of the ProxiWeb web proxy (love those innovative names) which used Mozilla (circa M6 or M8 I think) on Solaris x86 to format web pages for display on hiptops and Sidekicks. Later we built our own web proxy based on Mozilla 1.3, following a similar model but with all the lessons we learned maintaining the old code for years.

Eventually I ran away with the circus as one of the first employees at Flock where we were trying to re-imagine the desktop browser experience, based on Firefox. After a couple of years struggling with vision and execution they worked it out – soon after I left. Now it’s showing the potential of moving beyond the dominant Mosaic-with-tabs user experience that the main players are following.

Now I’m at Songbird, building another kind of browser – one whose focus is integrating media consumption and management. We’re building on XULRunner, the application platform that has been spun out from the Mozilla applications. It’s not my favorite platform for building applications, but how else are you going to build a cross-platform web browser.

Somehow this passing interest I had ten years ago has turned into a career.

I told you so

Posted on by
Reply

Six months ago I predicted:

This kind of bundling is often done by the bad guys. If you install Apple’s Quicktime codecs on Windows every update will trigger an iTunes install, even if you haven’t installed iTunes. I’m sure they’ll do the same thing for Safari on Windows. I’m not sure what iTunes’ market share on Windows is but it seems to be significant. If all those users suddenly have Safari installed that could potentially cause a big shake-up in browser market share.

On Friday there was a minor shitstorm on planet.mozilla.org about Apple pushing down Safari to all Windows iTunes and Quicktime users.

If only we had a reusable system-wide XULRunner it would be really easy to do similar but less evil promotion of our growing XUL-based free software suite. Songbird could suggest to users that they might like Firefox – and it would take just a single click and a tiny XPI download to have users running Firefox. We could even get intelligent and suggest Thunderbird to heavy email users or Flock to heavy social networking users.

iTunes’ US market share is around 27% (according to the best numbers I can find). If Apple flips the switch and makes Safari the default browser for all those users Firefox will start looking irrelevant fast.

Taming MacPorts

Posted on by
3

For the record, I don’t like MacPorts. I don’t like building software from sources when someone could have done it for me just fine. It’s a waste of fossil fuels and a waste of my time. Since my Mac doesn’t come with most of the software I’d expect I have to build things from sources. I tried doing this for a long time without MacPorts, but since everyone on the Mac installs all their software through MacPorts none of the portability patches make it upstream.

So I gave into the MacPorts software monopoly. There is, however no chance in hell I’m going to let it run as root and write whatever all over my filesystem – especially while the Mac doesn’t have a decent package management system I can use to restore system files that have been overwritten. MacPorts does, in theory let you install anywhere as any user. Just download the MacPorts tarball and configure with a few options:

./configure --prefix=$HOME/macports --with-install-user=ian --with-install-group=staff
make install

Just add $HOME/macports/bin to your path and you’re off. There do unfortunately seem to be a few limitations. Some packages like openssh want to install things as root. It looks like the MacPorts packaging is too coarse – you can’t install the client binaries without installing the server binaries. I guess I need to look into porting fakeroot.

Google AJAX APIs outside the browser

Posted on by
5

Google just announced their new Language API this morning. Unfortunately their API is another one of their AJAX APIs – that are designed to be used from JavaScript in web pages. These APIs are pretty cool for building client-side web applications – I used their AJAX Feeds API in my home page – but I had some ideas for server software that could use a translation API.

I remembered John Resig’s hack from a few months back, getting enough of the DOM in Rhino to run some of the jQuery unit tests. I pulled that down, wrote the bits of DOM that were missing and now I’ve got a Java and JavaScript environment for accessing Google’s AJAX APIs. Apart creating stubs for some methods that are called the main functionality I had to implement was turning Google’s APIs’ asynchronous script loading into the Rhino shell’s load(url) calls. They use <script src="... and document.createElement("script"), but both are pretty easy to catch. The upshot of this is that everything is synchronous. This subtly changes a lot of the interface. For example, my Language API example looks like this:

load('ajax-environment.js');
load('http://www.google.com/jsapi');
google.load('language', '1');
google.language.translate("Hello world", "en", "es",
  function(result) {
    print(result.translation);
  });

it of course prints: Hola mundo.

I’ve put the source up on github. Have a play, tell me what you think.

API Design

Posted on by
Reply

Recently at Songbird I’ve been working on some guidelines to help us build better APIs. One of the most exciting things we’re hoping to offer users and developers are APIs that give them access to their music and the ability to extend their and others’ music players. Getting these APIs right can be hard and we think we can do better, so we came up with some ideas and we’re trying to get some wider feedback.

Our guidelines come in two parts – general rules that apply across the board, and platform-specific conventions depending on what the specific APIs are based on (Mozilla Extension API vs Web Page JavaScript). Here’s our general guidelines:

  • APIs should be orthogonal and symmetrical
  • Method naming, argument ordering and error handling should be consistent
  • Code that uses the API should read like prose. Words should not be abbreviated. It should be easy to understand code that uses the API without having read the documentation
  • The API should follow the terminology, conventions and idioms of the platform that is is built on
  • Use cases and target developers should be taken into consideration when the API is being designed and documented
  • Developers should be able to continue to use the tools and libraries that they are familiar with when using the API. Their previous development experience should help them learn and understand the API quickly

These are based on research I did – I distilled half a dozen other peoples’ ideas about good API design into ones that we could easily apply to our own work.

The full document fleshes these out a little more, with examples and then goes into platform specific patterns to follow.

If you’re interested, read it and please send your comments.