Miguel de Icaza ([email protected])

This is the long promised write-up of the PDC trip. It has taken quite some time to digest what was unveiled there.

At the PDC we saw the latest ways in which Microsoft has pushed the operating system beyond its roots into an advanced operating system; far more than the universe of read(), write() and poll() that Linux developers usually think of as being "the OS."


Brady, Gonzalo, Lluis and myself went to the PDC, to check the latest product announcements related to the .NET Framework. We were in for a surprise. As I left the Boston airport, I confidently told Nat `Everything is under control, there will be some generics, some of this and some of that, will report back'.

I religiously sleep until noon, so waking up at 7am to attend the keynote conference was against possibly my most sacred principle. We had accumulated plenty of miles to be there and we were three hours behind Boston time, so I capitulated and was happily having breakfast at the conference center at 8am. By 8:10 I had already purchased a stack of books on ASP.NET 2.0, System.Xml 2.0, the new C# spec and the annotated CLI book. Me and the janitor were the only customers going through the books. For a second, the thought that the conference was empty crossed my mind, but the sales dude rapidly informed me that I had only 20 seconds to make it to the opening keynote. I ran.

The keynote

You probably have read about the keynote material everywhere by now. There were a few things announced:

There was a lot of wow-factor from the various demos as they were building them. They have this new file format called `Xaml' that is used to specify GUI layouts with XML. It was interesting that the demos were done with Emacs and VI. On one hand, they showed that there was no trick (or that these technologies were not `simplexity-based'), but on the other hand, I realized: they do not have a GUI builder for Avalon yet.

Xaml was particularly interesting, for Gnome people this is not news, but it is worth describing: the XML format binds the element names to .NET classes, and each one of the attributes maps to a property, so something roughly like:

<Window> <Button id="button" Background="Red"> <SimpleText>Hello</SimpleText> </Button> </Window>

The above gets translated with the XAML compiler into something like:

Window w1 = new Window (); Button button = new Button (); SimpleText s1 = new SimpleText ("Hello"); button.Items.Add (s1); w1.Items.Add (button);

So as you can see, pretty straightforward. Of course, the wow-factor comes when one of the attributes can be a video, and you can apply arbitrary Postscript-like transformations to the whole thing. Very much like Display Postscript-based systems, the MacOS or the venerable NeWS system (the difference being that Microsoft will drive this into every desktop, while the other systems never made it into the mass market).

One of the best moments of the keynote was the demostration by the guy from Amazon. They showed a beautiful GUI client, that was apparently fully written using Avalon in a month of work. I allocated a full 30 minute slot to a quest to reimplement it at home, and I can say with authority that 30 minutes are not enough.

During the next few days of the PDC, I attended the core CLR/.NET talks and the GUI ones; Gonzalo took on the ASP.NET ones and Lluis attended the Indigo talks. We met with Brady from the iFolder team at Novell, and he attended the WinFS talks.


My friend Benjamin knew that the Mono BOF had not been approved by the INETA folks, so he invited me to talk a bit about Mono on his own BOF on Sunday, the title was `Microsoft and Academia' (this is when we patched the main program to mention Mono). I did a small 5-minute presentation on Mono, and got to meet a few folks after the presentation.

On Monday, it was clear that we needed to put together another meeting. People on the hallways were asking when we would have the Mono meeting. In particular Sami Jaber who was covering the event for DotNetGuru in France volunteered to announce a new venue, and guaranteed `At least the French contingent will show up'. So we pulled out our maps, and found a perfect spot for the event: the Foyer that connected two hallways in the LA Conventions Center. We announced it on the relevant sites, and relevant blogs, and went on with life. Picking a time for a BOF was hard: there were pleny of other activities every day, so we basically picked the dinner time.

The day of the event, we went to pick up the Ximian/Mono T-Shirts to the hotel, we had plenty of time: 30 minutes to the BOF, and the hotel was only a few blocks away. Of course, we did not plan for one of those mythical traffic jams to play a role, and we managed to walk back from the hotel carrying boxes of t-shirts and being embarassingly late by 30-minutes.

Sami was there, and we started to gather a small group of people, but once the audience identified the t-shirts, we got together a pretty large group. The group took over all the available seats in the foyer, probably sixty to eighty people, hard to estimate.

I did a tiny introduction to Mono, really small, and then the next 90 minutes we spent them doing questions and answers. I got to meet various Mono contributors and regulars from the list: Dave Bettin, Kral Fretch, Urs Muff and plenty of actual users that do not hang around on the list. Since the audience was very .NET-savvy, that made my job a lot simpler, and the questions were fantastic. I like this format more than the regular formal Mono presentation, but I realize that this group of people was unique.

The introduction was basically the first ideas on what Mono 1.0 should be. The introduction, plus some of the insight from further discussion became the Mono Roadmap.

We now need to work hard on that roadmap and deliver on it. It is going to be hard.


Both Windows.Forms and XAML do layout of their widgets with some engine. The main mistake of Windows.Forms was not copying the constraint-based system that Gtk uses, and the Gtk containers that Gtk uses.

In .NET 1.2 they have an attempt to fix this by introducing various new widget containers: grids (tables), flows (not available on Gtk, but never needed it) and a few others. The main problem is that you have to "attach" the containers to its parent before you can do anything with them. A step in the right direction, but too cumbersome to use.

Hopefully, Avalon will promote a different model, a more sane one.

Xaml and Avalon

During the event everything was demoed by using this new markup language. Of course, everything produced with it looks terrible. And the reason is simple, XML might be a nice replacement for a few lines of code, but doing GUI layout in code is always a boring, error-prone, and most of the time the results are of low quality.

Xaml was pitched as a way of splitting the work between a designer and a programmer, which has an element of truth to it, but in reality they need a good GUI designer for producing interfaces (very much like Glade is to Libglade in Gnome).

Xaml is just a markup language that wires CLI classes together, so although it was demoed as a GUI composition tool, it could be used to wire together other components as well. My guess is as good as everyone else: it was probably intended to be a decent serialization format. A definite improvement for those folks building round-tripping IDEs, since now they only have to parse one language, and a fairly easy one to parse as well.

Now, the Avalon components that can be wired up have been built on its entirety on a new rendering framework, one that seems fairly powerful: a PDF like 2D imaging system, with video playback integrated.

This leads me to my first prediction: the first generation of Avalon applications will:

This brings me to the next point: the Microsoft folks, realizing that Avalon turn the rest of the century on the return of the <blink> tag on steroids, they have produced a number of interesting documents and on their public UI talks, they not only made fun of themselves, but they also have visibly taken the Joel-on-Software usability pill, and they are talking about the same thing we have been talking about in Gnome: usability, simplification, consistency.

Building rich desktop applications with Xaml is very easy: things can begin as "prettier" web pages. You do not have to be a programmer to use Xaml, and if you are, you can add extra functionality, just like Javascript does for the Web.

This of course poses a threat for the open source desktop, more on this on the upcoming sections.

New XML File Formats

Jon Udell in his blog points out that there are various new XML formats coming out of Microsoft that have some ammount of overlap with exising technologies: Adaptive Flow Format instead of CSS; Windows Vector Graphics instead of SVG; WinFS schema definition language vs Xml Schema.

At least for the first two, I can understand why the engineers rolled their own. It might not even be a case of not-invented here, it was just that given their model, it was just simpler to follow this path.

WVG/SVG is the obvious case where it might be convenient to bend the rules of Xaml: interop in this area is more important than the minimal benefit of integrating with the CLR. This is just just like coping with JPEG or GIF files: it is just not worth changing them.

From the Mono perspective, it is still an early technology to implement, but it is definitely an area that we are studying and we are hoping to produce some implementation guidelines for the most courageous developers. The core Mono team is right now working hard in producing Mono 1.0, and we are not planning on working on it immediately.

Avalon appears to be a large beast. I am left wondering if this is why the Microsoft developers have been talking about reducing the number of APIs exposed. It might be a good idea.

It might be interesting to build a smaller Avalon, one that could run on smaller devices, and would consume less resources would be a fun project.

Xaml as an HTML replacement.

Xaml is HTML merged with the Desktop UI

Although Xaml seems to be only a cute idea, it is simple enough, and each one of the individual components are powerful enough that it is very likely that Xaml could replace HTML as a way of creating rich content on Windows platforms. It would leave out of the equation Linux, Solaris and MacOS.

For free software users this again becomes a problem, since we continuously face proprietary protocols and file formats as a limitation of our platform. A limitation that we have to address every step of the way. In the case of Xaml, it is not the lack of documentation or a proprietary protocol, it is just that it is intimately tied to the .NET Frameworks.

Using Mono we will be able to bridge this gap: if people produce XAML-based applications and content, we want to be able to render that, and to do it right, we will have to implement the whole stack.

Various components will make XAML an attractive authoring environment:

A lot of fun work lies ahead of us.

ASP.NET 2.0 and XML 2.0

The good news is that the ASP.NET team surprised everyone: ASP.NET was already simple, and they made it simpler, and they added much wanted features like master pages, many small controls that factor-in common functionality on web sites. My personal favorite: pre-compiled deployment of web sites.

The XML folks did not stay behind: there are many new features: XQuery appeared in the framework and the new XPathDocument.

The bad news for Mono are thatn ASP.NET has more than doubled in size since the 1.1 release and the features in XML are fairly large improvements. The good news is that we were starting to get bored with the existing class libraries: largely bug fixing was the major focus, this injects a lot of fun into the Mono equation again.

For instance, a group is already working on an early implementation of ObjectSpaces.


The new storage facility to be available in Longhorn has some interesting features that have lead to lengthy debates in the Linux communities. WinFS will be released as part of Longhorn, so it will become available in 2006 and only to users that migrate to the new OS.

Brady explained to me WinFS, and his own project: iFolder 3.0. The features in WinFS will be available in Novell's own iFolder 3.0 by mid-next year. Both the workgroup client and the server will be open source offerings, and we plan on adding the same kind of GUI functionality that people saw at the PDC (the UI elements are being developed with .NET: Windows.Forms on Windows, and Gtk# on Unix).

iFolder is in fact one of the most interesting pieces of technology that Novell has been working on, and we hope to bring these features to Linux and Windows users (needless to say, before WinFS ships, and in more platforms than they will run ;-).

Some confussion still remains in the open source world about the inner working of the WinFS. WinFS does not replace the existing file system: it still uses it to store the actual bits of a file. WinFS basically is a layer that can extract interesting information from files when stored on it: the regular data goes into an underlying file system storage, and juicy metadata bits are extracted and recorded at this point. One possible use scenario of WinFS is to perform queries on the juicy information.

Jeroen and IKVM

Hacker extraordinaire Jeroen, the author of IKVM was also at the conference, and we got to hang around with him.

The Three Pillars

At this point you might have realized that the new three pillars of the new OS are:

More information on Indigo is available in Lluis' Indigo blog entry.

Closing remarks: A managed world.

Microsoft has taken another bold move in moving all of their new API development into .NET.

Not only are the new operating system features cool, but they have turned them into an API.

It is now our turn in the open source world to track these innovations, and expose turn applications into API providers.

It is important for Mono to continue its path (Note: we should do this in an orderly fashion, in peace if you will. Not screaming, waving our hands and banging our heads against the wall).

We have to leverage what is unique about Linux, iFolder, Gnome, Cairo, the VFS, our databases and expose those features to the managed world.

Mono needs to become a core feature of every application.