Thursday, December 07, 2006

.NET Click Once can Learn Something from a Web Browser

In my day job I get to write software and try to run a company. When I moonlight, I get to be a pundit. It's really quite fun-- while scurrying about the code preparing for a release I use one side of my brain. Once the release is out, I start writing and hopefully use the other side of my brain.

In this post I'll try to use both sides of my brain to support an argument I've presented over at Read/WriteWeb. Its a two-part article that basically states Microsoft holds all the cards for capturing the next generation of computing platform, IFF they can get past themselves and improve .NET just a little bit. That is, take a cue from what makes web applications great, apply it to the .NET framework and make rich applications great again.

The article points out how .NET can be improved, but several people claim .NET already has the feature I have in mind. I claim .NET has the marketing checkbox for the feature I have in mind, but not an actual, usable implementation of it. The market must think so to, because up to now 'Smart Clients' have gone nowhere.

When you build a web page, you write the html and include references to things that help you present a page: an image here, a nifty javascript widget there and a form button yonder. What you don't have to do is compile and link everything together-- the browser does it for you. Better yet, it uses the client machine to make smart choices about what to cache and what to update. Very rarely do you need to download all the pieces comprising a web app at one time again.

And when you need to download some pieces, you never see this:



or this:



This is the advantage web browsers and web apps enjoy over desktop apps today. The current solutions I've seen are not transparent. They involve checking for updated install files, which tend to be large for desktop apps, and reinstalling newer setup.exe packages.

I'd rather it be behind the scense and done piecemeal the web way. Two rules:

  • Don't Bug The User -- they don't care they are downloading updates to the app
  • Don't Bug The User -- they don't care they are reinstalling an app
When I make a change to a web application, everyone gets the updates on their next page refresh without any proclamations or calls to action. .NET apps, if they want to be smart, should do the same.

Obviously there are many ways to solve this problem, so this is just an example.

A .NET app still goes through two steps in order to run: compilation and linkage. After compilation, all the component parts of a .NET app are laid out as object files in a directory structure. Usually these object files are quite small. Then the linker performs the final assembly and produces a larger output-- executables or libraries.

What if, for deployment purposes, the linkage step is not done on a build machine, but on a clients computer? What if, when starting a .NET app, a 'smart linker' is used to check for updates by making HTTP requests once in a while to all the objects files referenced on a deployment server somewhere? Then, if it finds an object file or two has been updated, it pulls down a couple kilobytes of data, links it into the app and runs.

Then the next time user with a problem runs the app, they see the problem has been fixed and they write me a note saying, 'Thanks for fixing the problem'.

As a rich application developer and publisher, I want that.

No comments: