.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.

Microsoft and Novell Acrobatics with .NET

When I heard the news Microsoft inked a partnership with Novell, it had a certain surrealness about it. So much so that I half expected ignoring the news would somehow evaporate it by the end of the day. There just didn't seem to be enough depth to what should have been a shocking announcement. The best people could muster was 'former rivals.'

I see that C|Net is struggling with an adequate take as well. Is Microsoft pre-empting a fractured Oracle/Red Hat Anti-Alliance? Please. Microsoft hasn't been worried about Oracle for... ever. I think we can dismiss that one. Red Hat's revenues are a rounding error of an MS division. I'm not even seeing two sticks of wood, let alone smoke with that one.

It's got to be in the patents. So the question is why Novell and Suse? What makes it different from the other linux distros? The netware bogeyman has been beaten so thoroughly its barely even a rumor.

I think Microsoft has caught Mono.


A Little COMmiseration


When I started cutting my chops on programming, OLE, COM and Automation were the Next Big Thing. So I duitifully bought books, bravely fiddled with IDL and generally scratched my head at how unintelligible the Next Big Thing turned out to be. After a string of late night sessions trying to make object embedding work across applications for a customer, visions of Bill Gates in a flowing robe, and hat of moon and stars, sucking the aggregate programming energy of any potential competitor would flit across my bleary vision. Up until then I had never actually seen a hammer turned into a screwdriver. It's no wonder Java appeared on the scene.

But this isn't a comparison of programming models as much as admiration for how Microsoft has the ability, albeit when nudged, to right the ship and produce something great. Say what you want about Windows, Office, SQL Server and any other product, the one area Microsoft has always excelled in is developer tools.

Microsoft was nudged by Java. That's the one thing you can thank Scott McNealy for. And the result was they hired one of the best, if not the best, programming language designers in the world. Not only did they hire the best, but they inspired them too. Maybe it was money, or maybe it was a free hand to build the languages they wanted. Whatever the root, the result is the best development environment, the best development language and maybe even the best runtime.

In fact they did a bang-up job, and then shared the .NET runtime specification.


About Face


Even though .NET has been out for several years now, the office applications have been conscipously .NET free zones. It's very understandble: legacy code making billions of dollars that no one wants to touch. But now comes the need to take business productivity to the Web 2.0 era. Ray Ozzie has an excellent vision for melding the desktop with the web. It's time for the Office apps to move to a better platform.

Except that the last thing MS wants to see is their Office apps running on .NET. Or more precisely, running on .NET on a platform they can't influence. Yes they have produced software for Apple. MS Office for Apple even generates a nice amount of revenue. But Microsoft gets to decide what MS Office for Apple is and how it runs. If MS moved Office en masse to .NET, and if there's a .NET framework that can run on Apple or any other NIX, then users would get the exact same office experience regardless of platform.

The Mono project sponsored by Novell does exactly this. This would have the unfortunate effect of reducing the value of the Vista investment and their Windows cash engine. The underlying tension is between moving productivity apps into the future versus maximizing brand and return on investment.

While Microsoft once may have dismissed Linux in particular and open source in general, they now hold them with high regard. The last thing Microsoft would want is to open another front in a battle to maintain control of the desktop. Though it might seem far-fetched to view Mono being as large a threat today as Linux was yesterday, Microsoft can not afford to be wrong.

So Microsoft and Novell get together and on the surface talk about patents. However, my guess is it has more to do with .NET and Mono and keeping a genie in a bottle.