I have been using Subversion for my source code management (SCM) for several years now. It has followed me from Georgia Tech, through several personal projects, and two jobs. It is a well supported, well documented, and well understood product with thousands if not millions of users. Being a good developer, however, I find myself asking “what next?”

One answer, which has been implemented by Sun for their Java, OpenSolaris, and Netbeans projects as well as by Linus Torvalds for the Linux project is a decentralized, distributed SCM. In these systems, instead of having one single trunk, every interested party has their own trunk which people check out from. These changes are kept locally until it is pushed to or checked out from a remote tree.

In these systems a single maintainer is considered to be keeping the “golden” version. He is responsible for making sure that all checked-in code passes tests, conforms to code standards, etc. This is the version of the project which is considered stable. End users check out from him. He checks out from the Quality Assurance team when they report that their code has been checked for new bugs and problems. QA, in turn, checks out from developers and creative when they announce that they have finished work.

Linus Torvalds presented the Linux SCM system, Git, at Google and his speech can be found on YouTube.

For people who are interested, the solution from Sun is called Mercurial. Both are Free software.

I am a fan of biking, just ask any of my coworkers who have had the pleasure of seeing me haul into the office after a nice jaunt. I am also a application developer and web addict. Given the ubiquity of cheap wi-fi, the pleasure of not having to park or follow most traffic laws, and an investment in a laptop which weighs 3 pounds and has a 5 hour battery life, I tend to do a lot of work on the trail.

This has lead to an interesting problem. Most of my job is creating web applications which fail when you do not have any internet access. Now not being able to check my email when I am on the side of Stone Mountain may not be a problem, but not being able to update my spreadsheets, compose mail, or save my changes to the next great American novel is.

Many sites do not see the need for dealing with intermittent connectivity and instead take an all or nothing approach. Things are changing, needs are changing, and this attitude should change. Over the past few years there have been several technologies developed and proposed which mitigate these issues.

One that I have worked with is the Dojo Storage API. This API is a part of the Dojo project, an open source Javascript library. It provides wrappers for Adobe Flash’s shared object functionality which means that I can write Javascript code which will call Flash and save data to the user’s machine even if I am not online.

There are a few downsides to using the Dojo Storage API. First, a user must have Flash installed and must not have disabled shared objects. This is not a very large concern because of the large userbase of flash, however; Apple’s iPhone does not have a version of Flash and is not capable of using this API. Secondly, this API is part of the Dojo Offline SDK which has not had a stable release.

Of course this is still a far cry from an official, supported, implemented standard such as ones being proposed by the W3C (and subsequently ignored by Microsoft, Apple, Opera, Mozilla or bascially whoever DIDN’T propose the standard), but it offers a general step in the right direction.