Do you care about freedom? Got a free hour? Go watch Eben Moglen’s excellent keynote from the Plone conference. Moglen is a captivating speaker, and he manages to advance the argument for software freedom a lot further than even the devoted (like myself) would imagine possible.

The bottom line? Software freedom matters, because in a society that is primarily based on software, being able to duplicate our most essential product with marginal cost approximating zero is an opportunity we can’t miss with clear conscience.

Cheers, TonyG, for the recommendation.

It’s been a while since I started hearing rumors about LigHTTPd, a new free software web server that is gaining popularity, especially within the dynamic community. For a long time I dismissed it, though. Why the duplication of effort? After all, the free software community already has a very successful web server product - Apache. The problem is that Apache, while being a very complete product, is quite difficult to run. I never felt like I really mastered its configuration, for example - I usually end up just copying examples from other users and adjusting them, hoping that I got it right (and worrying that I probably missed something).

Recently I had to configure a FastCGI application to work in a mixed SSL and plain HTTP environment. Turns out Apache makes it quite difficult - it wont ship SSL as part of the product, and finding out how to configure it turned out to be far from trivial. Also, Apache1, that beloved monolithic monster, does have pretty good support for FastCGI via a module, but Apache2 doesn’t really have any good solution.

A few hours into the adventure I remembered LigHTTPd (pronounced lighty, usually) and thought I might as well give it a try. A quick sudo apt-get install lighttpd later I have it up and running - SSL support is built in, and it only took me five minutes to self-sign a certificate and get it going. FastCGI was just as easy. The first thing I noticed is how quickly the server starts up - that might not sound like an important feature, but in a development environment, where I tend to restart the server regularly (anybody knows of a better way to force a FastCGI application to reload, b.t.w?) it’s very nice to have. There was also a noticeable improvement in the speed of serving disk-based resources (the improvement in performance, according to the benchmarks is indeed quite impressive). What really bought me, though, was the configuration - Lighty’s configuration style is so intuitive, and after just a few minutes of playing with it I had the feeling that I know how to do most of what I wanted - there’s a uniform syntax for setting parameters or adding items to lists of parameters, and statements can always be qualified with a rule (only for a certain domain, or port, or matching an expression on the query, you-name-it).

Here, for example, is what my configuration looks like (with some comments):

# HTTPS support for the entire subdomain
# (note that the rule could be anything at all)
$SERVER["socket"] == "myapp.mydomain:443" {
  ssl.engine = "enable"
  ssl.pemfile = "/path/host.pem"
  ssl.ca-file = "/path/host.cert"
}

# Configuration for my application's subdomain
$HTTP["host"] == "myapp.mydomain" {
  # Add an alias to the filesystem path of my app code
  alias.url += ( "/the-app/" => "/path/to/app/code/" )

  # Set-up the FastCGI server
  fastcgi.server = ( "/the-app/app-script.fcgi" =>
   (( "socket" => "/tmp/fastcgi.socket",
      "bin-path" => "/path/to/app/code/app-script.fcgi",
      "max-procs" => 1
   ))
  )

  # Rewrite rules
  url.rewrite-once = (
    # Use Lighty to serve static resources
    # it's much faster that way!
    "^/(css|js|images)/(.*)$" => "/the-app/$1/$2",
   # Rewrite all other urls to be served by the application
   # So that I can construct pretty URLs
    "^/?(.*)$" => "/the-app/app-script.fcgi/$1"
  )
}

If you’ve ever had to configure Apache, you’ll immediately notice how much nicer Lighty’s format is, and with performance being as good as it is, I think I will now default to using Lighty whenever I can. If you need a good web server, give Lighty a try, you wont be disappointed!

Reading through tonyg’s recent post I came across something i haven’t yet seen in use - inline XML within Javascript code. E4X, it seems, has landed. It is now available by default in Firefox and Rhino - other implementation will surely follow.

E4X, shorthand for ECMAScript for XML is a nice language extension to Javascript adding native XML support. It adds XML types, a notation for literal XML and some basic operations. Previously, if you wanted to use XML in your Javascript code, you had two choices. Since XML has a textual representation, you could work with strings. This approach, however, is extremely error-prone, and is of limited use if you intend to do anything more sophisticted than just generating XML. The other approach is to use the XML DOM, which exposes the full power of XML using a consistent model, but is too verbose and so rather unpleasant to use.

Example: XML using strings / innerHTML

// Short, but notice how I forgot to close the paragraph
// Also, this is non-standard, and only works in HTML
myElement.innerHTML = '<p><b>Hello</b> <i>World</i>';

Example: XML using the DOM

// That must be one of the longest hello world
// examples I've ever written
var paragraph = document.createElement('p');
var bold = document.createElement('b');
var hello = document.createTextNode('Hello');
bold.appendChild(hello);
var italic = document.createElement('i');
var world = document.createTextNode('World');
italic.appendChild(world);
var space = document.createTextNode(' ');
paragraph.appendChild(bold);
paragraph.appendChild(space);
paragraph.appendChild(world);
myElement.appendhChild(paragraph);

As it happens, I am working on something that requires quite a lot of DOM manipulation within the browser, and tired of constructing XML using the DOM API I set to give the new E4X capabilities of Firefox 1.5 a try. The dissapointing reality, I soon found out, is that while E4X is very much present, it can’t be used for accessing or creating DOM elements. So if you plan on parsing some XML data, or generating XML from your program you can use E4X, but DOM manipulation, arguably the most important activity involving XML in a browser is not served by this new extension at all.

Example: How E4X could be used with the DOM

// This is structured XML, notice how there are no quotes
var p_xml =  <p><b>Hello</b> <i>World</i><p>;
// But unfortunately you can't do that
var p_element = document.createElement(p_xml);
myElement.appendChild(p_element)

Javascript is a complete, general-purpose language, but in practice, it is being used exclusively as an extension for host environments. In Firefox, for example, it is used for adding program logic to the browser’s display formats - HTML, XUL and SVG. These formats can be expressed in text, but in order to manipulate them you need to access them using the DOM. For HTML, firefox adopted the nasty innerHTML non-standard extension, which allows the user to access the contents of a node as text. Fortunately, this extension doesn’t work with non-HTML elements. E4X could have been the perfect replacement - a compromise between using the dumb textual representation and the structured, but counter-intuitive DOM.

Why doesn’t Firefox provide a way to construct and manipulate DOM elements using E4X? It’s hard to blame the mozilla developers, given that the ECMA standard does not include any mention of the DOM or how to interact with it. Any extension they would have come up with would end being the next generation innerHTML non-standard.

This failure of the E4X standard, together with tonyg’s previous critique of E4X, as well as other rumours from the Javascript development arena have me wondering whether the standartisation efforts by ECMA have greatly benefited the language and its active community.