Longhorn through the open source lens

We asked two open source leaders — Brendan Eich, chief architect of Mozilla, and Miguel de Icaza, CTO of Novell’s Ximian services business unit — for their perspectives on Longhorn’s Avalon presentation subsystem.

IW: What’s your take on Avalon?

BE: Microsoft’s doing things that are valid according to their business interests and also, in general engineering terms, with an eye toward the [professional developers]. They have to keep them happy, give them the tools they want, keep them hooked on the next version of the OS.

IW: Of course, a lot of those folks tell us that the browser and the Web are their bread and butter.

BE: That’s my fond hope, too. I’m sure there will always be certified Windows developers. But I do wonder if they’ll have trouble convincing people to migrate and pay large costs to reinvest in redoing things — especially if they’re not supporting the Web well and if people find the Web to be lower cost yet still adequate for presentation.

MdI: Avalon is a very extensive API, but while there is a lot of abstraction, there is not enough encapsulation. It’s a high-level standard toolkit. The problem we have today with Unix toolkits, Mac OS toolkits, and Windows toolkits is that we are still using the same controls. Developers and designers are building applications in terms of the following items: scroll bars, enter lines, buttons, text entries, radio buttons, pop-up menus, combo boxes. Avalon is not presenting us with new controls or innovative ways of dealing with large volumes of data. And yet this massive API says you have to be completely bound to a particular version of the .Net Framework. This is not the approach the Web has taken, which is that a table or button can be rendered in different ways appropriate to the platform.

BE: That’s right. If you look at XAML’s style language, they really muddle the presentation/structure separation.

MdI: Avalon is the next ActiveX. One thing that is a problem when trying to do Linux desktop rollouts is that companies often have a few proprietary ActiveX components. Avalon will be a lot easier to write than the previous ActiveX; it’s a lot prettier, so when organizations are using Longhorn-based machines, which I assume will be sold everywhere by 2008, it’s going to be increasingly hard for the rest of us to get there unless we have an implementation of an equivalent technology. So, eventually somebody will implement that, whether as part of the Mono project or a separate project.

IW: It’s been argued that because there are 15 ways people have approached XUL [Extensible User Interface Language], Flex, XAML, whatever — and you can’t reconcile them — maybe it’s time for a de facto standard implementation.

BE: XAML is not that thing, though, because, as Miguel says, they’ve bound it too tightly to their class structure. And that surprises me because they should have institutional memory of all the versions of OLE and all the hell they had to go through in terms of compatibility glue. Do they want to do that again?