2 <head><title>Mono Hacking Roadmap</title>
3 <style type="text/css">
7 font-family: "Trebuchet MS";
15 font-family: Verdana,sans-serif;
31 border-bottom: 2px solid #dddddd;
35 border-bottom: 2px solid #dddddd;
39 background-color: #ffffff;
40 font-family: Verdana, sans-serif; font-size: 12px;
71 <font size=1>Miguel de Icaza (<a href="mailto:miguel@ximian.com">miguel@ximian.com</a>)</font>
77 <h3>Introductory notes</h3>
79 <p>The intention of this document and the <a
80 href="http://www.go-mono.com/mono-roadmap.html">Mono
81 Roadmap</a> is to be a basis for discussion. I want to build
82 on these two documents, and update as we get more insight into
83 the release process and the technologies we want to ship.
87 <p>At the 2003 PDC Microsoft introduced many new technologies,
88 which many of us are very excited about. To me, it underlined
89 the importance of having a roadmap for users of Mono
90 technologies. That way they know precisely what to expect
91 from us when. We have been working on Mono for more than two
92 years, and it is important that we release a stable product to
95 <p>We have various degrees of maturity and feature
96 completeness in our code base, and I do not believe that we
97 should aim to be full implementation .NET 1.0 or .NET 1.1 in
98 our 1.0 release, that would just push the release at least for
100 href="http://www.go-mono.com/mono-roadmap.html">Mono
101 Roadmap</a> emphasizes this assumption.
103 <p>The 1.0 release is critical for the adoption of Mono on the
104 Linux environment, even if it is not as complete as the
105 Framework, lets get something stable, and fun to people to
108 <h3>Mono 1.0: missing functionality.</h3>
110 <p>For the 1.0 release, there are a number of features that we
111 will have to complete, in no particular order:
114 <li>We need to fix corcompare and our cor-compare
115 pages to support both 1.0 and 1.1 API API compares.
117 We might want to move this outside of the Mono site,
118 to reduce the complexity of the HTML hackage, and use
119 ASP.NET to implement this. Bonus points if we use
120 Piers' nice dynamic tree to load the CorCompare data
123 <li>Global Assembly Cache: Needed to support the
124 parallel installation of .NET 1.0 and 1.1 assemblies,
125 and to fix the various Assembly loading routines.
129 <li>ECMA profile: We will like take care of this one
132 <li>Assembly signing: I do not know what is the state
133 of this feature currently in Mono, maybe Sebastien and
134 Zoltan could give us an update here.
136 <li>ASP.NET caching: Non-existant at this point, this
137 needs to be implemented.
139 <li>Stability of ASP.NET and Mod_Mono. They are both
140 functional, but they fail under load. Much debugging
141 and testing must go into these components. As we use
142 more of it, we have found more little problems surface
145 <li>Codebase audit: Duncan did an audit of Corlib, but
146 we must do an audit of all the assemblies that we we
147 are going to ship, just to get an idea of the major
151 <p>The team at Novell will focus on these areas. We of course
152 welcomes the contribution of the rest of the Mono team and
153 encourage the developers to focus on 1.0, to have a solid
154 release, and a solid foundation that can lead to 1.2
156 <p>We will use Bugzilla milestones to track these issues.
158 <h3>Synchronized releases</h3>
160 <p>It would be great if we can ship Mono 1.0 with Gtk# 1.0 and
161 a preview of Monodoc with the early documentation.
163 <h3>Alpha components.</h3>
165 <p>Various Mono developers are working on areas that will not
166 make it into the 1.0 timeframe: JScript, WSE, VB.NET,
167 Windows.Forms, Generics. We should continue to work on
168 those components, as they will come shortly after, and they
169 are probably more fun to develop than stabilizing the core.
171 <h3>New components: Whidbey and Longhorn features</h3>
173 <p>Everyone is probably very excited about the new features in
174 the Whidbey release of .NET, and most importantly the Longhorn
175 features. I am sure that many of us will not resist the urge
176 to put some of the new assemblies on CVS.
178 <p>We will likely add a profile for those of you that want to
179 work on this, and can not wait to get your hands in the code,
180 although keep in mind that your contributions wont reach the
181 general audience until we successfully ship 1.0.
183 <p>The things to keep in mind while adding code which is not
184 in .NET 1.0 and .NET 1.1:
187 <li>Make sure you surround new classes and methods
188 with the appropriate define: NET_1_2 for things
189 available on the .NET 1.2 SDK (Whidbey) and NET_3
190 define for things only available on the Longhorn API.
191 We need this so that these methods do not appear on
192 the 1.0 and 1.1 builds.
194 <li>If you add generic types or methods, also surround
195 the method with GENERICS for now, since our compiler
196 can not currently build this code yet. This is
197 redundant with the NET_1_2 define but important.
199 <li>For every assembly you update, make sure that you
200 also add the relevant AssemblyInfo versioning
201 information. If possible, when you add methods from
202 .NET 1.2 to the build, also update the AssemblyInfo.cs
206 <p>There are three areas of new hot features:
209 <li>Class library improvements (Whidbey, Mono 1.2
212 <li>Indigo: They will release this in 2005 or 2006 and
213 wont make it into the 2004 Whidbey .NET 1.2 release.
215 <li>Avalon: Definitely a Longhorn-bound feature.
218 <p>Most code that will reach the users in the short time frame
219 (next year) will be related to the Whidbey improvements, so I
220 encourage developers to work on those pieces, as they are the
221 ones that will help Mono the most.
223 <h3>ASP.NET 2.0 plans</h3>
225 <p>Gonzalo will continue to coordinate this effort; At this
226 time ASP.NET 2.0 features will not make it into Mono 1.0.
228 <h3>Avalon plans</h3>
230 <p>On the surface Avalaon seems like it uses something like
231 GdiPlus/Cairo for rendering. That was my initial feeling, but
232 it turns out that they had to rewrite everything to have a
233 performing rendering engine, and implement some very advanced
234 rendering features that include compositing with video
235 streams, also their brushes seem to be fairly powerful.
237 <p>XAML, a new markup language that binds tags to .NET classes
238 was also presented, but this is the least interesting part. A
239 tiny compiler translates the XAML source files into C# code.
240 The whole process is just like Glade, and should be easy to
243 <p>The really elaborate parts are the rendering engine, and the
244 composition model for widgets. It is a complete new toolkit,
245 and if we want to implement this one, we will have to have a
246 new toolkit on Unix, incompatible with everything else, maybe
247 stressing the importance of working with other open source
248 projects in defining a cross-toolkit theming strategy to
249 address this particular problem.
251 <p>A Mini-Avalon is easy to do, but a complete one will
252 require much interaction with other groups: the Cairo folks
253 are probably the most qualified to assist us.
255 <h3>Indigo Plans</h3>
257 <p>Indigo is still an early product (<a
258 href="http://msdn.microsoft.com/Longhorn/understanding/pillars/Indigo/default.aspx?pull=/library/en-us/dnlong/html/indigofaq1.asp">FAQ</a>),
259 but it could benefit from continued development of our WSE1
260 and WSE2 components, later to bring some of the code to it.
262 <p>Again, since people are visibly excited about this
263 technology, we will lay down in the next few days a framework
268 <i>Last Updated: Nov 1st, 2003</i>