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.
I own
it now.
I will be talking to some Novell customers in
Mexico City about Novell Linux initiatives and some of the
Novell offerings on Thursday September 20th, if you want to
come, register 
I found this link from Jon Udell's blog: 
