Let’s say you’ve got a method that receives a string describing some state (“normal”, “error” etc.). And depending on the value of that string (state) you want to react.

If you ask around, an OOP afficionado might tell you to replace the switch with classes and use polymorphism. Yeah, well, that’s not the greatest of solutions – you just replace an ugly statement with a handful of ugly classes. Functional programming fan would tell you to use pattern matching (A.K.A. “case statement on steroids”), which would work nice…only you’re stuck with an imperative language. Tough luck. So, isn’t there another way?

No, there isn’t.

Nah, just kidding. Turns out we can use a neat little design pattern familiarly reffered to as “lexical dispatch” (see this article about a similar pattern in Python).

Observe:

myDispatcher = {};

myDispatcher.dispatch = function (eventName /*, other args...*/ ) {
    // Get the handler.
    var handlerName = "handle" + _.string.capitalize(eventName.toLowerCase());
    var handler = this[handlerName];
    // Handle unknown event.
    if (!_.isFunction(handler)) {
        throw _.string.sprintf("ERROR: Handler for event %s not found!", eventName);
    }
    // Call the handler.
    handler.apply(this, _.tail(arguments));
}; 

myDispatcher.handleNormal = function(msg, details) {
    console.log(_.string.sprintf("Everything is %s...%", msg, details));
}; 

myDispatcher.handleError = function(msg, details) {
    console.log(_.string.sprintf("%s...%s", msg, details));
};

myDispatcher.dispatch("normal", "just, you know...fine");
myDispatcher.dispatch("error", "AAAAARHG!", "AAAAAAAAAAAARGH!");

(We’re using underscore.js and underscore.string.js in the example).

The important piece is the myDispatcher.dispatch method. It takes any number of arguments, but the first one is a state string. We use it to construct the name of the handler that will be invoked for that particular state.

So:
myDispatcher.dispatch(“normal”,…) is delegated to handleNormal.
myDispatcher.dispatch(“error”,…) is delegated to handleError.
myDispatcher.dispatch(“foo”,…) would be delegated to handleFoo.

If we want to add a new state, it’s as simple as adding a new method to myDispatcher. No more searching for that ugly case statement.

And a big boo-yah to static languages .

Jasmine is a JavaScript framework for supporting behaviour-driven development in your projects.

Like most JS frameworks, when used for client side development Jasmine expects an environment that meets certain conditions (e.g. it assumes the existence of a global window object).

In Salsita, however, we’re in the business of creating browser add-ons – which happens to mean that most of the time, some of those conditions are not met.

In the world of XUL-based Firefox add-ons, code is (or should be anyway) usually structured in code modules, which import each other and are themselves imported from the XUL window in a manner similar to HTML. This provides a nice way to encapsulate the logic into individual files. Furthemore, Firefox add-ons can use a special console application, xpcshell, that allows for relatively convenient (and more importantly – fast) automated testing of these modules. When it comes to BDD (and Jasmine in particular), however, there are some flies to be found in our agile testing ointment.

First, as has already been said, there is no global window object. That should come as no surprise, since, well, xpcshell is a console application. Luckily enough, when we go through Jasmine’s code, it is clear that we need just a handful of methods from the window object – namely those related to timers: setTimeout, setInterval and the respective clear* counterparts. Hence, the solution is easy – we make a fake window object and fob it off to Jasmine.

/**
 * Fake global window object and some global functions (used to allow us to
 * import scripts that require those). */
var EXPORTED_SYMBOLS = ["window", "setTimeout", "clearTimeout", "setInterval", "clearInterval"];
if (!Cc) var Cc = Components.classes;
if (!Cu) var Cu = Components.utils;
if (!Ci) var Ci = Components.interfaces;
var window = {
    document: {},
    location: {},
    setTimeout: setTimeout,
    setInterval: setInterval,
    clearTimeout: clearTimeout,
    clearinterval: clearInterval
};
var _timers = [];

function setTimer(fun, timeout, type) {
    var timer = Cc["@mozilla.org/timer;1"].createInstance(Ci.nsITimer);
    _timers.push(timer);
    var event = {
        notify: function (timer) {
            fun();
        }
    };
    timer.initWithCallback(event, timeout, type);
    return timer;
}
function setTimeout(fun, timeout) {
    return setTimer(fun, timeout, Ci.nsITimer.TYPE_ONE_SHOT);
};

function setInterval(fun, timeout) {
    return setTimer(fun, timeout, Ci.nsITimer.TYPE_REPEATING_SLACK);
};

function clearTimeout(timer) {
    if (!timer) {
        return;
    }
    timer.cancel();
    var i = _timers.indexOf(timer);
    if (i & gt; = 0) {
        _timers.splice(_timers.indexOf(timer), 1);
    }
}
var clearInterval = clearTimeout; 

We’re going to import this fake window object in the head_init.js fixture file that is run before the tests in our test directory (in the newer Firefox versions, you have to specify the fixtures in the xpcshell.ini file).

An important point to note is that we do not want to use the standard Component.utils.import call to import Jasmine within our tests. Doing that would require changes to the library code, because JS code modules expect exported symbols to be specified explicitly using EXPORTED_SYMBOLS. Instead, we use mozIJSSubScriptLoader and load the library into the test scope (after importing the fake window object).

var loader = Cc["@mozilla.org/moz/jssubscript-loader;1"].getService(Ci.mozIJSSubScriptLoader);
loader.loadSubScript("resource://myAppId/frameworks/jasmine.js");
loader.loadSubScript("resource://myAppId/frameworks/jasmineReporter.js");

Next, we create the alias so that resource://<addonid>/ URLs map to the correct path (and the Cu.imports in our modules work when the code is run in xpcshell). The following snippet is taken from a recipe on MDC.

file = do_get_file(".", false);
var ioService = Cc["@mozilla.org/network/io-service;1"].getService(Ci.nsIIOService);
var resProt = ioService.getProtocolHandler("resource").QueryInterface(Ci.nsIResProtocolHandler);
var aliasURI = ioService.newFileURI(file);
resProt.setSubstitution("myAppId", aliasURI);

And we’re almost there! The last thing is to make sure the BDD specs are actually run. Jasmine runs all the specs asynchronously, whereas xpcshell expects synchronous tests. That means if we don’t tell xpcshell to wait until the specs have finished, none of the specs will actually be run. Therefore, we use a little trick here.

// Initialize Jasmine BDD framework.
var jasmineEnv = jasmine.getEnv();
var reporter = new jasmine.ConsoleReporter(dump, function(runner) {
  var results = runner.results();
  if (results.failedCount > 0) {
    // throw using xpcshell do_throw to report an error (and make the test fail).
    do_throw("Test failed");
  }
  // Inform xpcshell that we're done.
  do_test_finished();
}, false);
jasmineEnv.addReporter(reporter);
function runSpecs(specFun) {
  // Tell xpcshell that we're doing asynchronous stuff.
  do_test_pending();
  // Load the test suite.
  specFun();
  // Run the test specs.
  jasmineEnv.execute();
} 

The runSpecs function is to be called from the test_* files that contain the actual test code (the parameter is a wrapper function for the Jasmine test suite). It sets a “pending” flag that tells xpcshell we’re running something asynchronous here and it should not quit right away but rather wait for us to signal that we are done.

We’re using the reporter’s callback function to check whether all the specs have been run. If there were any failures, we call xpcshell’s do_throw to make the test fail (which quits the tests, so there’s no need to unset the pending flag). Otherwise, we just unset the flag and – we’re done!

In essence, Mozilla wants to focus on creating the best browser possible. The distractions inherent in maintaining a platform for third-party developers (then XULRunner, now sophisticated extensions) undeniably detract from this goal. But what if being the best browser, in the sense of being truly differentiated from the competition, actually means that Firefox must be a great platform? In tackling the Chrome insurgent by seeking parity with its rapid release schedule, simple extension API, sparser user interface, process-isolated tabs and so forth, Firefox may be losing its strongest reason for existing.

Firefox is underpinned by a remarkably flexible platform. Most of the core functionality of the browser is organized around components that can be accessed (usually from JavaScript as well as C++) via well-defined interfaces. The user interface is specified using a declarative markup language and can be modified almost arbitrarily using overlays that add, change or remove stuff. The component model resembles and is doubtless inspired by Microsoft, which has a muscular platform of its own (as Steve points out). The UI extensibility is far beyond anything I’ve seen in other desktop software.

The peerless extension ecosystem that has grown up around Firefox is a direct result of the strength of its platform. You can make Firefox do pretty much anything with an extension, including many things that the browser’s creators could never have imagined when they designed it. The platform is also the reason why many parties (present company included) have tried at various junctures to promote the platform-as-a-product known as XULRunner. Considering the scope of its ambitions, the platform seemed underutilized to them. This idea was considered and eventually rejected by Mozilla in 2007.

Various subsequent decisions and initiatives imply that Mozilla is now pursuing a path of “deplatformization” for Firefox: deCOMtamination, the thawing of all XPCOM interfaces, the death blow struck to binary XPCOM components and the new, much more limited Add-on SDK.

Granted, the Firefox platform faces many intimidating challenges. Inevitably, many interfaces could do with a redesign. XUL is proprietary and being overtaken by newer revisions of HTML. XBL is great when it works and baffling when it doesn’t, due to patchy error reporting. There is a general lack of good tools when compared to other modern software platforms. The macro-laden C++ syntax is ponderous and doesn’t make much use of the last 15 years of language innovations. More fundamentally, all the cool but unexpected extension functionality that hooks into relatively low-level platform features has put Firefox into a straightjacket that inhibits its evolution.

Killing off the platform is one solution. It’s hard not to be jealous of Chrome, a green-field development free of the shackles of third-party legacy code. Why not become more like Chrome then? Not a platform, just a damn good browser. Focus on responsiveness and minimalistic user interface design, arguably the main drivers of Chrome’s rise to 25% (or so) market share in only three years. Slim down the add-on SDK so that extension developers have enough rope to skip but not enough to hang themselves.

Perhaps this path will prove fruitful, but to me it’s hard to see how Chrome can be dethroned by chasing its tail. Firefox has a much stronger play to make: face the issues with the current platform head-on. Replace the XUL user interface with HTML 5. Develop and deploy tools on par with those available for iOS and .NET. Redesign interfaces that have proven inadequate (they’re mostly pretty good in my experience). Make a commitment to Firefox developers to converge on a set of stable, actively maintained and well-documented interfaces.

I won’t dwell on the arguments for why a strong platform is important. Steve Yegge makes a more compelling case in his 4500-odd words than I ever could. For Firefox the case has even more resonance because it represents a return to its platform-centric roots.

Firefox 7 uses less memory than Firefox 6 (and 5 and 4): often 20% to 30% less, and sometimes as much as 50% less. In particular, Firefox 7?s memory usage will stay steady if you leave it running overnight, and it will free up more memory when you close many tabs.

This sounds like real progress even if the figures cited seem a bit overblown, based as they are on an artificial scenario (opening 150 browser windows on a machine with 16Gb of RAM). Web pages take up RAM mainly because their in-memory representation (DOM) is large. Browsers with a lot of pages open unavoidably use a lot of memory (and I can attest personally that Chrome is no exception). It therefore makes sense to focus on areas where big improvements can be made, like freeing memory more quickly when pages are closed. Don’t expect memory usage to halve during real world usage, but it should improve significantly if you open and close pages a lot (and who doesn’t?).

The other memory-related improvement is to memory consumption when the browser is left idle. Apparently this is related primary to a subtle bug introduced in Firefox 4. As a result, JavaScript garbage collection was not being triggered in some cases (especially on machines with limited RAM).

“Impossible,” I said. “Remember Google’s motto is Don’t Be Evil. They wouldn’t do anything as sneaky as that.”

Nonetheless, my curiosity was piqued and I googled around (oh, the irony!) to see if anyone had reported something similar. Sure enough, this immediately turned up some mozillaZine forum posts and a blog entry by an outraged German blogger. I fired up a clean Windows virtual machine, installed Firefox, headed to the Adobe Flash Update page and — holy hound of hell! — it turns out to be true:

Now software bundling is a widely practiced — if vaguely creepy — way of distributing software, but to me this crosses an invisible line (particularly in light of Google’s self-professed non-evilness). I’ve just installed Firefox, and the first thing Adobe does is propose to install Chrome? At very least, the link should be an opt-in rather than opt-out. (The rule of thumb I’ve heard is that about 80% of users download opt-out software versus 20% for opt-in.) It’s a bit sad that Google is willing to go to these lengths to grow market share. And it’s arguably even sadder that Adobe hasn’t come up with a better way to monetize the enormous number of Flash downloads they serve.

As the pundits would have it, Netflix is a basket case run by a bunch of nincompoops who can barely dress themselves in the morning, let alone run a fast-growing media company. The funny thing is until a couple of months ago, they were perceived as having some of the savviest top management in Silicon Valley. This was reflected by their success in a cutthroat market, with nearly 30% of total internet traffic (yes, you read that right) attributable to their streaming service.

So how did Netflix go from superstar to pathetic loser almost overnight? The answer is simple: they didn’t. They are continuing to execute brilliantly in a market littered with dismal failures among both incumbents and hype-fueled startups. Their recent pricing changes and even more recent split into two companies (one for DVDs and one for streaming) is hardly a refutation of this brilliance. It’s a symptom of it.

The irony is that the same digerati who constantly mock Big Media for failing to “get it” are the first to bash Netflix when they demonstrate that they do. The DVD-by-post subscription service was an exceedingly clever and well-executed hack. Sending a bunch of bits back and forth on a clunky disk is slower, more expensive and more wasteful than streaming, but it got around the lack of bandwidth and the thorny copyright issues that existed when the service was launched. Needless to say, it’s been a stunning success, and a lesser company would cling to it for dear life. Eventually some nimble startup would eat their lunch with a modern digital delivery service unburdened by a legacy DVD business. Everyone would laugh at how the hidebound former market leader had failed to adapt.

But Netflix has done everything right. They’ve separated the two services and prepared for a time in the not too distant future when DVDs will be obsolete. The stock movements mean nothing except that the normal myopic herd mentality of day traders and institutional investors continues to reign supreme (and as a newly minted shareholder, I thank them). As Andy Grove would say, Netflix has reached an inflection point and has rightly focused on where the market is going, not where it is today. They deserve praise, not mockery, for having the foresight and courage to avoid the trap that the vast majority of successful companies succumb to.

The conversation started when someone commented that Kevin Rose (of Digg fame) couldn’t get milk.com for his new company and had to settle for mi.lk instead. (Just my luck that no country has claimed the .ta top-level domain.) The guy who owns milk.com simply isn’t interested in selling. Well actually he’d probably sell for $10 million, which would make it the second most valuable domain of all time. Heaven knows, if there’s one thing people like almost as much as sex, it’s milk.

What struck me about the discussion was that Twitter and Facebook handles are now discussed in the same breath as domain names themselves. Leo is not just bitter that he can’t have www.leo.com, he’s equally bitter that he can’t be twitter.com/leo or facebook.com/leo. In other words, if you’re an established company or want to seem like one, you’ve got to go out and haggle with not one, but three separate parties in order to get all your social naming bases covered. If the future is more diversity of private services for communicating with the greater public, the problem is only going to get worse.

Now if you’re Kevin Rose then you can call up your buddy Mark Zuckerberg and your other buddy the-guy-who-runs-Twitter and ask them to kick out those dirty lousy squatters so you can have cool vanity domains on their services. In a way this is a good thing since those squatters really are shockingly dirty and appallingly lousy. On the other hand, it seems a bit unfair that the well-connected would have this recourse when normal folks do not. At least the URL situation applies to everyone equally. (To be clear, this isn’t a dig — no pun intended — at Kevin Rose, as I’d do the same thing in a heartbeat if I could.)

I still feel the market is the best way to allocate domain names. It may seem unfair that some geeky dude with a strange sense of humor has been sitting on milk.com for so long that he stills declares it a “blink-free zone”, while giving the middle finger to people who could put it to much better use. But, as your parents used to tell you, life isn’t fair, and it’s no less irksome when someone far less intelligent, charming, good-looking and talented than you is worth a fortune because their great uncle bought a brownstone in Manhattan for $400 in the 1920′s that’s now worth zillions.

On the other hand, a sound principle can be taken too far, and it doesn’t seem plausible that successful businesses and well-funded startups will have to engage in negotiations with an increasing number of social service squatters in addition to bidding on the domain name of their dreams. This strengthens the already compelling case for decentralized identity. After all, we never had to worry about getting a cool name for our RSS feed back when people still used RSS. We just tied it to our domain. Hopefully the same will be true of our activity streams in the future.

This is the situation with WebRunner today. According to Mozilla Add-ons there are between 5000 and 6000 active users. To put this in perspective, consider that the 100th most popular add-on has almost 200,000 users. At the same time, I know from many public and private conversations that the product has its share of ardent fans. I strongly believe that with sufficient effort in technology and marketing, the product could be a top add-on with a much larger user base.

One problem is that this effort carries a huge opportunity cost. Salsita is flourishing and the 10-20 hours/week I spend personally on WebRunner is precious time that I could otherwise spend managing our growing team, developing our business and exploring various exciting side projects that are currently undernourished. The lamentable fact is that we’ve been neglecting WebRunner for a while for exactly this reason, and it would now need significant work to turn it into a hit product. This includes deep architectural changes like moving away from binary XPCOM and towards js-ctypes, which is essential now that Firefox releases break binary XPCOM compatibility. It also means integrating a host of newer web standards (e.g. for desktop notifications) that didn’t exist when WebRunner was first released.

Moreover, the logical place to get WebRunner-like functionality is from the browser vendors themselves. Chrome has been offering this for ages (though lamentably Mac support still requires some hacking). Internet Explorer 9 has pinned sites. The day that Mozilla catches up and releases this functionality, WebRunner will be rendered instantly obsolete.

Mozilla is now discussing exactly this, and personally I see this as great news. I’m sad to see WebRunner go but a whole lot happier to see its legacy live on where it truly belongs: built into Firefox. I do hope that some of the concrete ideas and even code from WebRunner will be picked up by the Mozilla team. I also hope that they will take the opportunity to mine an incredible resource: the ideas, impressions and lessons that the users of the Prism and WebRunner can offer after using these products over the past four years.

What does this mean?

As of today, Salsita Software will no longer be actively maintaining the free version of WebRunner. We submitted the latest version (for Firefox 6.0) to the Mozilla Add-ons site last week and expect it to be approved in the next week or so. We will not be releasing new versions after that, so as soon as Firefox 7.0 comes out, WebRunner will no longer work.

We will make the source code available, and if anyone wants to take over maintenance of the code base, they are welcome to do so. Be forewarned, however, that with the amount of binary code in WebRunner, building release versions on all platforms every six weeks is a considerable effort that has contributed to our decision to discontinue the product.

Naturally we remain interested in working on single-site browser projects for clients, whether based on WebRunner or not, and we have unparalleled expertise in this area. In particular, if your company is using WebRunner and you would like to discuss continued maintenance, don’t hesitate to contact us.

The good news is that Stefan has created a much more user-friendly tutorial (with screenshots and everything). Thanks, Stefan! The one drawback is that the tutorial is Windows only. If anyone feels like whipping up something similar for Mac and/or Linux, that would be stupendous.

As I mentioned in my last post, I have an internal version of a simple packager that I’ve written to automate this process (on Windows and Mac). I’ve had a few requests for it, so I’m planning to check whether it works with the latest Firefox and, if so, put it up somewhere over the next week or so for people to play with.