Avalon Throwaway?

Miguel de Icaza sees problems in the way that Avalon is being developed and predicts that Avalon 1.0 won't be able to develop sophisticated applications and will eventually be thrown away, resulting in incompatible code for version 2.0. Miguel, I believe, created Gnome, works in Novell and is involved with Mono, so he has a lot of relevant experience.

I just want to point out that this is the second iteration of Avalon, and this version is, according to Chris Anderson, simpler, more flexible, and more performant than the original version. (So, the first version of Avalon was indeed throw away and Miguel may actually be right in a way unintended.)

He points out a few issues.

Security
Miguel has no problem with the .NET's solution of code access security model, but he believes a more serious security has been left unaddressed. Since Avalon provides full control of the user interface to application developers, it leaves the door wide open for low-tech security holes involving social engineering and phishing, especially since it will now be possible to click-once and run an Avalon applications from the network.

I agree. The Longhorn security model records the source of an application, so that it can apply the appropriate level of security permissions to the application, wherever it eventually is executed. However, Avalon, and, Longhorn, in general needs to provide a standard visual mechanism to indicate the true source of the application.

On the other hand, these same issues exist for all applications, be they WinForms or web-based.

Complexity
Miguel looks at the inheritance chain for an object like Button and sees complexity in its ten levels of inheritance (in contrast, Button in WinForms has 5 levels of inheritance). Miguel continues to discuss the implementation issues were exposed everywhere.

But, I look at the same issues  and see something different. WinForms is a wrapper around the Win32 API, whose implementation is buried in native code with no internal types exposed in the metadata; as such, hierarchy is much flatter. In Avalon, all the implementation is in managed code, leading to additional base classes that must be exposed; I also forgot to mention that Avalon does far more. (I do have to admit that Apple's Cocoa has 5 levels of inheritance for NSButton, but perhaps it is because internal types may be easier to hide in Objective C or that NSButton is itself a wrapper class?)

The many level of classes in the inheritance chain do appear to be well-factored and sensible. Avalon needs richer base-level object support than the CLR provides. The UIContextObject provides support for a sensible threading model than WinForms, by allowing objects to be manipulated in any thread, but only one thread at a time. Dependency object provides rich property and event handling that includes databinding, animation, undo, attached properties, validation, and so on.

As for complexity, programmers don't typically pay much attention to the base classes, anyway. What they care about is being able to use objects and extend objects in a simple fashion. I think Avalon has achieved that goal. One of the tenets of Avalon, I believe borrowed from Smalltalk, is to "make simple things simple, and hard things possible." There's also a direct intuitive correspondence between declarative XAML and procedural .NET code.

Miguel also mentions that the framework is not fully cooked yet, but the product is two years away. I myself was surprised by the limited growth of the Avalon API in the WinHEC build from the PDC build. It appears that the Avalon team may have still been porting the plumbing from the original Avalon tree to the new tree, replacing NotYetImplemented exceptions with working code. I guess that it's not reasonable to assume 2 years of development of original Avalon tree to be ported to the new tree in just a few months. (But there's been some progress beyond the port; the 3D controls, I don't think, existed in the older tree.) There may also have been some diversion of effort due to the XP Service Pack 2 effort.

Ignoring Standards
I wrote about this earlier in my post on XAML and Standards.

Retained Mode Graphics
I viewed a PDC conference slide on creating and extending controls, and "retained mode" graphics is clearly not the only means of extension. In fact, Avalon supports several layers of rendering graphics, from simple  high-level element composition all the way down to the immediate mode graphics that Miguel say scales better for commercial applications. There are many advantages to retained mode, such as performance and remote display.

Lack of a GUI designer
There have been a number of rumors about a Microsoft GUI designer, called a Flash killer, on the web. I haven't seen it, though, but I am aware of that each Avalon control (including shape elements like Rectangle, Ellipse, etc) supports design-time editing, as this was demoed at PDC, so I probably wouldn't be hard to build.

Misc
Here are some other points as to why Avalon will likely be ready for commercial applications.

Avalon is designed to last another generation. This is accomplished by future-proofing its API. One such mechanism is the ubiquitous use of abstract base classes and interfaces to support decoupling between implementations. Other examples include restricting floating-point values to double-precision--favoring API longevity over memory and performance, and representing each component of the Color object with floating point value.

Another Avalon tenet is that Avalon developers should "dogfood their own extensibility" mechanism to prevent the phenomenon in Win32 and WinForms, where Microsoft developers used a robust extensibility model internally and provided a weak or inadequate model to the outside world.

The one thing that I am cautious about is performance, since Avalon places heavy stresses on the runtime, exposing any scalability problems. Avalon constructs a lot of objects. On the other hand, those demands will probably lead to an earlier maturity of the runtime.

 

Comments

[Miguel de Icaza]

Yes, the first Avalon was thrown away
before the PDC. By the PDC they already
had their second implementation.

Am worried that due to the time constraints
this one will also be a throw-away and a
new, incompatible Avalon will have to
emerge after this cycle.

Miguel

[.]

How can Sparkle be a Flashkiller if it uses Avalon?

This does not make sense.