Asynchronous Updating

Logging into the virtual environment, users began to notice that the frequency of system updates began to increase, eventually culminating into passive updates streaming behind the scenes. Dynamically updating the protocols and software did away with cumbersome batch updates and awkward installations from the past. Rightly so, it was noted, because the near constant updates would have made it completely impossible to utilize the technologies in any other manner, and each time the users logged into their accounts, the virtual environment greeted them with more to offer and ever higher fidelity.

At some point during the past week while I was making final corrections and edits to my book chapter in the upcoming book Virtual Worlds and E-commerce: Technologies and Applications for Building Customer Relationships I had a revelation upon logging into the Second Life virtual environment. I currently use the Viewer 2 alpha for testing purposes and to participate in the JIRA feedback and bug reporting, however I noticed something interesting over the past few days that I don't believe really hit home previously.

The plot to this blog entry is found in the initial quote (from my chapter) which outlines how the progression of updates will be handled in a virtual environment program as accelerating returns begin to take hold. If you aren't aware, accelerating returns is the speeding up of paradigm shifts over time, and in terms of software and how people handle their information, I make the assumption that it will be commonplace to begin doing passive updates to software rather than direct bulk updates.

When you log into a software system such as Second Life, quite often you are greeted with a message saying that a newer version is available and you must download and install it before you can continue. I find this method to be ill-conceived at best in the 21st century, and would go so far as to say that asynchronous updating should be the preferred method for software updates going forward.

There is no need to wait until a person runs the software to inform them that a new version is available, force them to quit the program, download the new version, install it, and then continue. When faced with the alternatives, it seems quite silly that software still does this, and I can only stare in wonder and ask "Why?".

So what's all this about "Asynchronous Updating", you may ask? Well, it's nothing spectacular or new; it's simply the order of how updates are handled that is changing. Take, for instance, if the software does an update check and finds that there is indeed a newer version of the software available. Instead of telling you a newer version exists and prompts you to quit the software application to download the new version and install it, the following should happen:

1. You execute the program
2. It checks for new versions or updates
3. If it finds updates or a new version, it downloads it in the background to it's own temp folder.
4. User continues to use the old version of the program unhindered
5. When user closes the program, and later restarts it, the updates are automatically applied as part of the start-up process.

This is more of a passive updating system, or transparent update system whereby the experience is not abruptly interrupted for a mandatory update. In the meantime, they continue to use the old version unhindered and without a noticeable interruption. When they run the program again later, the updated version which was downloaded in the background is installed before running the main software.

I believe as release times shorten, and updates for software become more numerous, this sort of asynchronous update system should be used. What do you think?