web/mono-hacking-roadmap.html

<html>
<head><title>Mono Hacking Roadmap</title>
<style type="text/css">
h1 {
color: #efefef;
font-size: 18pt;
font-family: "Trebuchet MS";
border: 0;
margin: 0;
padding: 1em;
background: #666666;
}

h2, h3, h4, h5, h6 {
font-family: Verdana,sans-serif;
font-weight: bold;
margin: 9pt;
}

h2, h3 {
font-size: 18px;
}

h2 {
padding: 3px;
color: #000000;
}

h3 {
font-size: 13px;
border-bottom: 2px solid #dddddd;
}

h4 {
border-bottom: 2px solid #dddddd;
}

body, table {
background-color: #ffffff;
font-family: Verdana, sans-serif; font-size: 12px;
color: black;
margin: 0;
padding: 0;
border: 0;
       margin-left: 20%;
       margin-right: 20%;
}

p {
margin-left: 2em;
margin-right: 2em;
}

ul li {
margin-left: 2em;
}

img {
border: 0;
vertical-align: top;
}

</style>
</head>
<body>
<center>
  <h1>
  Mono Hacking Roadmap
  <br>

  <font size=1>Miguel de Icaza (<a href="mailto:miguel@ximian.com">miguel@ximian.com</a>)</font>

  </h1>
  <p>
</center>

<h3>Introductory notes</h3>

	<p>The intention of this document and the <a
	href="http://www.go-mono.com/mono-roadmap.html">Mono
	Roadmap</a> 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.

<h3>Background</h3>

	<p>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.

	<p>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 <a
	href="http://www.go-mono.com/mono-roadmap.html">Mono
	Roadmap</a> emphasizes this assumption.

	<p>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. 

<h3>Mono 1.0: missing functionality.</h3>

	<p>For the 1.0 release, there are a number of features that we
	will have to complete, in no particular order:
	
	<ul>
		<li>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. 
		
		<li>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.

		<li>PowerPC port.

		<li>ECMA profile: We will like take care of this one
		at Novell.

		<li>Assembly signing: There are two ways to sign 
		assemblies.<br>

			<b>StrongNames</b> - 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:
			<ul>
				<li>The runtime doesn't check
				strongname signatures (if present) 
				when loading an assembly outside the
				GAC;
				<li>sn.exe cannot be used to sign, 
				nor verify, an assembly that contains
				the "ECMA public key";
				<li>sn.exe doesn't support all options
				to turn on/off runtime verification
				for some assemblies;
				<li>StrongNameIdentityPermission 
				support isn't complete as it depends
				on CAS.
			</ul>

			<b>Authenticode</b> - 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:
			<ul>
				<li>Currently our X.509 certificate
				chaining is very limited and we do 
				not support certificate revocation 
				in anyway;
				<li>Not every options are implemented
				in all tools (and some do not really
				apply to Mono);
				<li>PublisherIdentityPermission 
				support isn't complete as it depends
				on CAS.
			</ul>

		<li>ASP.NET caching: Non-existant at this point, this
		needs to be implemented. 
		
		<li>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. 

		<li>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.
	</ul>

	<p>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

	<p>We will use Bugzilla milestones to track these issues. 

<h3>Synchronized releases</h3>

	<p>It would be great if we can ship Mono 1.0 with Gtk# 1.0 and
	a preview of Monodoc with the early documentation.  
	
<h3>Alpha components.</h3>

	<p>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. 

<h3>New components: Whidbey and Longhorn features</h3>

	<p>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.

	<p>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.
	
	<p>The things to keep in mind while adding code which is not
	in .NET 1.0 and .NET 1.1:

	<ul>
		<li>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.

		<li>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. 
		
		<li>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.
	</ul>

	<p>There are three areas of new hot features:

	<ul>
		<li>Class library improvements (Whidbey, Mono 1.2
		time frames).

		<li>Indigo: They will release this in 2005 or 2006 and
		 wont make it into the 2004 Whidbey .NET 1.2 release.

		<li>Avalon: Definitely a Longhorn-bound feature.
	</ul>

	<p>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.  

<h3>ASP.NET 2.0 plans</h3>

	<p>Gonzalo will continue to coordinate this effort;  At this
	time ASP.NET 2.0 features will not make it into Mono 1.0.
	
<h3>Avalon plans</h3>

	<p>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.

	<p>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.

	<p>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.

	<p>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.

<h3>Indigo Plans</h3>

	<p>Indigo is still an early product (<a
	href="http://msdn.microsoft.com/Longhorn/understanding/pillars/Indigo/default.aspx?pull=/library/en-us/dnlong/html/indigofaq1.asp">FAQ</a>),
	but it could benefit from continued development of our WSE1
	and WSE2 components, later to bring some of the code to it.

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

<p>
<i>Last Updated: Nov 1st, 2003</i>
		
</body>
</html>