Mono Hacking Roadmap
Miguel de Icaza (miguel@ximian.com)

Introductory notes

The intention of this document and the Mono Roadmap is to be a basis for discussion. I want to build on these two documents, and update as we get more insight into the release process and the technologies we want to ship.

Background

At the 2003 PDC Microsoft introduced many new technologies, which many of us are very excited about. To me, it underlined the importance of having a roadmap for users of Mono technologies. That way they know precisely what to expect from us when. We have been working on Mono for more than two years, and it is important that we release a stable product to the public.

We have various degrees of maturity and feature completeness in our code base, and I do not believe that we should aim to be full implementation .NET 1.0 or .NET 1.1 in our 1.0 release, that would just push the release at least for another year . The Mono Roadmap emphasizes this assumption.

The 1.0 release is critical for the adoption of Mono on the Linux environment, even if it is not as complete as the Framework, lets get something stable, and fun to people to use.

Mono 1.0: missing functionality.

For the 1.0 release, there are a number of features that we will have to complete, in no particular order:

• We need to fix corcompare and our cor-compare pages to support both 1.0 and 1.1 API API compares. We might want to move this outside of the Mono site, to reduce the complexity of the HTML hackage, and use ASP.NET to implement this. Bonus points if we use Piers' nice dynamic tree to load the CorCompare data dynamically.
• Global Assembly Cache: Needed to support the parallel installation of .NET 1.0 and 1.1 assemblies, and to fix the various Assembly loading routines.
• PowerPC port.
• ECMA profile: We will like take care of this one at Novell.
• Assembly signing: There are two ways to sign assemblies.
  StrongNames - It is possible to sign and verify strongname signatures using the sn.exe security tool. This same tool can also create the required key pairs to sign the assemblies. What we are lacking:
  • The runtime doesn't check strongname signatures (if present) when loading an assembly outside the GAC;
  • sn.exe cannot be used to sign, nor verify, an assembly that contains the "ECMA public key";
  • sn.exe doesn't support all options to turn on/off runtime verification for some assemblies;
  • StrongNameIdentityPermission support isn't complete as it depends on CAS.
  Authenticode - It is possible today to sign assemblies (in fact any PE file) with an Authenticode(r) compatible signature (with or without a timestamp) using the security tools cert2spc.exe and signcode.exe. We also have support to test this using the tools makecert.exe, chktrust.exe and setreg.exe. What we are lacking:
  • Currently our X.509 certificate chaining is very limited and we do not support certificate revocation in anyway;
  • Not every options are implemented in all tools (and some do not really apply to Mono);
  • PublisherIdentityPermission support isn't complete as it depends on CAS.
• ASP.NET caching: Non-existant at this point, this needs to be implemented.
• Stability of ASP.NET and Mod_Mono. They are both functional, but they fail under load. Much debugging and testing must go into these components. As we use more of it, we have found more little problems surface on it.
• Codebase audit: Duncan did an audit of Corlib, but we must do an audit of all the assemblies that we we are going to ship, just to get an idea of the major areas missing.

The team at Novell will focus on these areas. We of course welcomes the contribution of the rest of the Mono team and encourage the developers to focus on 1.0, to have a solid release, and a solid foundation that can lead to 1.2

We will use Bugzilla milestones to track these issues.

Synchronized releases

It would be great if we can ship Mono 1.0 with Gtk# 1.0 and a preview of Monodoc with the early documentation.

Alpha components.

Various Mono developers are working on areas that will not make it into the 1.0 timeframe: JScript, WSE, VB.NET, Windows.Forms, Generics. We should continue to work on those components, as they will come shortly after, and they are probably more fun to develop than stabilizing the core.

New components: Whidbey and Longhorn features

Everyone is probably very excited about the new features in the Whidbey release of .NET, and most importantly the Longhorn features. I am sure that many of us will not resist the urge to put some of the new assemblies on CVS.

We will likely add a profile for those of you that want to work on this, and can not wait to get your hands in the code, although keep in mind that your contributions wont reach the general audience until we successfully ship 1.0.

The things to keep in mind while adding code which is not in .NET 1.0 and .NET 1.1:

• Make sure you surround new classes and methods with the appropriate define: NET_1_2 for things available on the .NET 1.2 SDK (Whidbey) and NET_3 define for things only available on the Longhorn API. We need this so that these methods do not appear on the 1.0 and 1.1 builds.
• If you add generic types or methods, also surround the method with GENERICS for now, since our compiler can not currently build this code yet. This is redundant with the NET_1_2 define but important.
• For every assembly you update, make sure that you also add the relevant AssemblyInfo versioning information. If possible, when you add methods from .NET 1.2 to the build, also update the AssemblyInfo.cs for the library.

There are three areas of new hot features:

• Class library improvements (Whidbey, Mono 1.2 time frames).
• Indigo: They will release this in 2005 or 2006 and wont make it into the 2004 Whidbey .NET 1.2 release.
• Avalon: Definitely a Longhorn-bound feature.

Most code that will reach the users in the short time frame (next year) will be related to the Whidbey improvements, so I encourage developers to work on those pieces, as they are the ones that will help Mono the most.

ASP.NET 2.0 plans

Gonzalo will continue to coordinate this effort; At this time ASP.NET 2.0 features will not make it into Mono 1.0.

Avalon plans

On the surface Avalon seems like it uses something like GdiPlus/Cairo for rendering. That was my initial feeling, but it turns out that they had to rewrite everything to have a performing rendering engine, and implement some very advanced rendering features that include compositing with video streams, also their brushes seem to be fairly powerful.

XAML, a new markup language that binds tags to .NET classes was also presented, but this is the least interesting part. A tiny compiler translates the XAML source files into C# code. The whole process is just like Glade, and should be easy to do.

The really elaborate parts are the rendering engine, and the composition model for widgets. It is a complete new toolkit, and if we want to implement this one, we will have to have a new toolkit on Unix, incompatible with everything else, maybe stressing the importance of working with other open source projects in defining a cross-toolkit theming strategy to address this particular problem.

A Mini-Avalon is easy to do, but a complete one will require much interaction with other groups: the Cairo folks are probably the most qualified to assist us.

Indigo Plans

Indigo is still an early product (FAQ), but it could benefit from continued development of our WSE1 and WSE2 components, later to bring some of the code to it.

Again, since people are visibly excited about this technology, we will lay down in the next few days a framework to contribute to it.

Last Updated: Nov 1st, 2003