Longhorn changes

Last week's announcement of the changes in Longhorn were interesting: the backporting of Avalon and the removal of WinFS from the mix.

It was clear that the only way to get Avalon adopted was by backporting it in some capacity to older operating systems. By June 2004 XP had 51% of the market while 40% of the market was still held by Windows 95, 98, ME, 2000 and NT. This is after three years of XP having being available to the public.

If Longhorn was going to ship in 2006, developers could not target Avalon as their UI for at least another three years, Microsoft's recommendation was just as disheartening. Of course this is assuming that Longhorn would have the same adoption rate as Windows XP.

Incidentally, this was the reason why we decided to redo our Windows.Forms implementation: if Avalon was not going to be common platform for development until 2009 people would continue to target the Windows.Forms API. The announcement from last week closes the gap.

As I have discussed earlier, Avalon is the latest edition of developer lock-in to the Microsoft platforms and the decision making process is driven by this more than technically. If the need arises, it can be implemented in open source as an interop measure, but it is an effort that will take time.

Avalon has a few problems, the following is from my impressions from the latest code that has been made available to the public:

Security: Although Avalon and .NET address the high-tech problem of secure sandbox execution, it fails to provide a low-tech solution for impersonation, and other forms of tricking a user into providing personal information (credit card numbers, Social Security).

These scams are a serious problem today in the Web but we at least have the url bar. But rich clients make this harder for and end-user to distinguish. Of course some simple solutions exist, but nothing comprehensive enough to guarantee that novice users will not be tricked.

The issue at stake here is that the feature (in this case a large API, feature-full and hard to reproduce) is driving the project, with security being cooked as an after-thought. As I said: the high-tech solution has been dealt with (the sandboxed execution environment) but not the low-tech problems. And the low-tech problems are resposible for most of the viruses affecting the Windows world today.

As we have seen, education of the user base is not really a solution and leaving security as an after-thought has proved very dangerous so far.

Complexity: The Avalon API has a very large surface area. To get an idea, the Button class is number 11 on the inheritance chain with ButtonBase, ContentControl, Control, FrameworkElement, UIElement, RetainedVisual, Visual, DependencyObject, UIContextObject and Object as its base classes.

The implementation details transpire everywhere, and approach that I believe is a bad idea: there is little or no encapsulation of things.

Avalon is clearly not fully cooked, at least it was not a few months ago when simple things like keyboard manipulation were not fleshed out. My feeling is that large changes are still required.

Ignoring Standards: I understand why someone would invent their own version of SVG or their own version of CSS: those standards can be difficult to implement, and growing your own version is a lot simpler than having to adapt an existing model to a new model.

I would have probably done the same if I had been in their position: its easy. But I would think that Microsoft has a higher responsibility towards the developer base that must create tools that interop with third party components: creating a new standard for graphics just because its `easy' is not really a good answer.

Implementing SVG might have problems and limitations, but the advantages outweight these problems: there are plenty of tools today to produce and consume it and it fits better with the rest of the industry. A benefit that Avalon users will not have and will just partition the industry again for a fairly poor reason.

Canvas model: Avalon's canvas model suffers from the same problem every other retained system suffers: they are hard to scale in the general case. We know this because Gnome has such system and its the basis for a couple of widgets and controls in applications like Evolution, Gnumeric.

The model is fantastic until you have to scale it; And when you have to scale it, you have to fall back to the traditional programming model where you have to roll your own repaint and handle all the low-level details yourself.

In general, I think its a great idea, but it is a limitation on which the rest of the system is built on.

Lack of a GUI designer: Avalon today lacks a GUI designer, an effort that so far people have not noticed, because developers have been told that XAML is the new way of doing things and declarative programming is hip.

Declarative programming is a cute idea (not new: its just the XML version of the old Windows resource files; or Gnome's glade files or MacOS X NIB files). The reality is that XAML is a serialization format that could be manipulated by tools, but the tools so far have been missing.

Predictions

My prediction is that Avalon v1 will be a throw-away: it is not really the foundation on which you will build applications: V2 will likely not be backwards compatible, they will have to re-architect bits of it: which means that people will end up with two frameworks running side-by-side: Avalon V1 and Avalon V2.

The above problem is compounded with the fact that the CLR has not really sorted out a good model for sharing components across versions of the framework: the GAC solution today is a bit of a hack to keep things separate and allow for multiple installations, but falls short.

This is like cooking, you can not rush a good steak, or a cake or an omelette by cranking the heat. Some things just take time.

In a way the .NET Framework was like this: it was slowly cooked and it reached a great point (it could still be improved) but some of the new code is just not ready.

In Gnome for example we ship immature APIs but we do not make them part of the developer platform: they have to simmer and marinate for a while before they make it into the official SDK.

Death March?

When I read Dave Winer's comment on Avalon and the Death March, I realized that the Avalon folks now must do two products instead of one: they need to build an Avalon for Longhorn, and another Avalon that will run on XP. It seems that they just added a pile of work to a team that was not ready to release their software.

I watched Allchin's interview over at Channel9, and he looks nervous: he is addressing two audiences at once the winners and the losers: the external developers who get Avalon on XP, and the internal developers that have just been dumped a new set of tasks and challenges. He is walking a fine line.

I do not think I could have solved a problem of this magnitude, am sure the complexity is huge and the Microsoft folks are doing their best, but maybe a change in the way that features are interlocked and how those are delivered to users must be rethought.

When it comes to operating system releases, I believe that Apple has found the sweet spot: a combination of best practices from the industry and best practices from the open source world. In addition to this, the versioning setup that Apple ships for the Frameworks seems to be pretty good on the surface. Update: I fixed some embarassing typos.