Quoderat

I recently heard from an older computer user who was delighted that his hotel’s free WiFi simply worked with his notebook computer. Internet access on the road didn’t use to be so easy, either for hotels or their guests. Consider these three (hypothetical) hotels:

1. In 1995, hotel #1 spent a lot of money to redo its digital phone system to make it compatible with computer modems.
2. In 2000, hotels #1 and 2 spent even more money to run Cat 5 (Ethernet) cable to all of their rooms
3. In 2005, hotels #1, 2, and 3 spent much less money to set up a few WiFi hotspots.

A quickie moral would be that hotel #3 came off better, since it ended up in the same place for a fraction of the cost, while the other two suffered from a first mover disadvantage. Reality, of course, is more complicated.: hotels #1 and 2 had five years to amortize each of their earlier investments. If those investments allowed them to steal guests from hotel #3, or to charge higher rates, then the investments may well have turned a net profit for the hotels.

The real moral is that the one that the extreme programming advocates push: build for today. As long as hotels #1 and 2 were investing in technology that their guests needed right away (rather than at some ill-defined point in the future), they probably came out OK. On the other hand, if a hotel were putting in technology just because, some day, it might be needed, it probably saw that technology superceded before it could bring in any return.

If this moral seems simple and obvious when applied to hotels, then why do architects ignore it sometimes when designing information systems for big enterprise and government? When we sell them on something like WS-* (or a REST-based data architecture), what criteria do we use to figure out whether we’re building for today, or for a tomorrow that may never come?

Bill de hÓra is outraged that people are blaming Google Web Accelerator (GWA) for following HTTP GET links, rather than blaming the morons^H^H^H^H^H^Hweb developers who built web sites that use innocent-looking GET requests for actions with side effects, like (say) delete or launch missile attack.

I don’t know if GWA itself is useless hype, an evil conspiracy, or a good thing (I suspect some combination of the first two), but Bill’s right that the assumption that it’s always safe to follow a GET link is one of the basic pillars of the web. Initiating a potentially dangerous action in response to a GET request is on the same level as putting a “wings fall off” button on the arm of an airliner seat — sure, we’d prefer that the passenger not hit the button, but why is the button there in the first place?

My creaky little Piper Warrior has been grounded since a lighting strike (while tied-down on the apron) back in July, but the engine’s finally back from overhaul, and I plan to be in the air soon — just in time, in fact, to sputter my way down from Ottawa to Atlanta to speak at the XML 2005 conference. I’m planning a 7-8 hour flight down if weather permits, with stops in Watertown NY (to clear customs) and in either Pittsburgh PA or somewhere in West Virginia to refuel. I flew myself to XML 2003 in Philadelphia as well, but that was a much shorter (and non-stop) flight.

Is anyone else flying to the conference in a small plane? Perhaps we can set up an informal general aviation BOF. I’m looking forward to seeing you all there — even the non-pilots, of course.

Is it possible (for webapps, that is)? Is it desirable? Current practice is to set up a session on the server side, then use the cookie (or a GET parameter or URL substring) as a key to associate individual HTTP requests with sessions.

There are some alternatives to cookies and URL rewriting — and even to server-side sessions themselves — that will work under many conditions:

• With HTTP authentication, the browser will resend credentials for each page, at the cost of a bit of extra HTTP overhead (the first time a page is viewed, there will be an extra exchange with the server, at least for Firefox). The user id can make an effective session key, and, in the case of authentication alone, can eliminate the need for sessions altogether.
• For multi-stage, choreographed processes, using a separate URL for each stage — in the best spirit of REST — eliminates the need to track the user’s progress as part of the session information, and also makes it easier for the user to bookmark a step halfway through the process and return to it later.
• It is also possible to stash temporary information in POST parameters: though some toolkits might balk, it is possible to have both GET and POST parameters to the same POST request, where the POST parameters won’t mess up the URL (though they will cause browser complaints with page reloading).

None of these is a perfect substitute for sessions, but I wonder if we haven’t used sessions and session variables a bit too much, just because toolkits have made them so easy to use. There’s also the philosophical problem that using any extra-URL technique (cookies, HTTP authentication, etc.) to customize a page violates the REST principle that n requests with the same URL should return the same object.

Who reading this has implemented a reasonably-complex webapp without using cookies or URL rewriting? What about a webapp that doesn’t use sessions at all?

Tim O’Reilly reprinted a note from Andy Oram about Oracle’s recent purchase of InnoDB, the company that produces the best of the MySQL backends.

Assuming that Oracle knows what they’re doing (generally a safe assumption), the purchase is not an attempt to attack MySQL as an Open Source product, and it certainly shows no weakness in the Open Source model or the choice to use Open Source in the enterprise. Oracle’s lawyers are smart enough to understand that since InnoDB was released under the GPL, they cannot prevent others from forking the code and continuing development. Anyone — from private users to LAMP websites to large enterprises — can continue to use MySQL with the InnoDB backend under the GPL no matter what Oracle says or does.

What Oracle can now prevent, however, is dual licensing of InnoDB itself and any future forked version. Unless Oracle gives permission, InnoDB can be licensed only under the GPL, which means that it can be used as the backend only for a GPL-licensed database. MySQL AB, the company that produces MySQL, earns a chunk of its revenue from dual licensing, and when their contract with InnoDB runs out in a year and a half, they will no longer be able to distribute a non-GPL version of MySQL that uses InnoDB. So here are Oracle’s next two likely moves:

1. Oracle continues to develop and improve InnoDB, releasing its changes under the GPL, winning kudos from the Open Source community, and encouraging even more users to switch MySQL and InnoDB.
2. Oracle does not allow MySQL AB to renew its contract for dual-licensing InnoDB, weaking a potential competitor even while it helps an Open Source product.

In other words, MySQL extends its lead as the predominant Open Source database, but MySQL AB loses its dual-licensing revenue source and becomes a less effective commercial competitor to Oracle. Nice move. Looking over the pieces on the board, I can see two ways for MySQL to respond to this threat:

• create a new backend to replace InnoDB in the 1+ year remaining of MySQL AB’s InnoDB contract; or
• forget about dual-licensing, make MySQL exclusively Open Source, and concentrate on support revenue.

The first move isn’t as good an idea, since Oracle will be able to use its own code and expertise to keep improving InnoDB to be faster, more conformant, etc., giving it effective control of the game while MySQL AB is constantly reacting. Heck, Oracle can even fork its own version of MySQL, as long as it stays GPL. The second move, on the other hand, will give MySQL AB back the initiative by allowing it to benefit from any work Oracle puts into InnoDB — the better Oracle (or anyone else) makes InnoDB, the more revenue MySQL AB can pull in for supporting a pure-Open Source MySQL.

If there’s any lesson in this, it’s that the dual-licensing business model has some serious flaws. Stick with selling support and professional services.