| blob | 134a1d425412fd51c2b2754a5c7beb949543d754 |
1 <html>
4 h1 {
12 }
18 }
22 }
24 h2 {
27 }
29 h3 {
32 }
34 h4 {
36 }
47 }
49 p {
52 }
54 ul li {
56 }
58 img {
61 }
63 </style>
64 </head>
65 <body>
66 <center>
67 <h1>
68 Mono Hacking Roadmap
69 <br>
73 </h1>
74 <p>
75 </center>
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.
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
93 the public.
95 <p>We have various degrees of maturity and feature
96 completeness in our code base, and I do not believe that we
98 our 1.0 release, that would just push the release at least for
99 another year . The <a
101 Roadmap</a> emphasizes this assumption.
104 Linux environment, even if it is not as complete as the
105 Framework, lets get something stable, and fun to people to
106 use.
111 will have to complete, in no particular order:
113 <ul>
114 <li>We need to fix corcompare and our cor-compare
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
121 dynamically.
123 <li>Global Assembly Cache: Needed to support the
125 and to fix the various Assembly loading routines.
127 <li>PowerPC port.
129 <li>ECMA profile: We will like take care of this one
130 at Novell.
132 <li>Assembly signing: There are two ways to sign
133 assemblies.<br>
136 and verify strongname signatures using the
137 sn.exe security tool. This same tool can also
138 create the required key pairs to sign the
139 assemblies. What we are lacking:
140 <ul>
141 <li>The runtime doesn't check
142 strongname signatures (if present)
143 when loading an assembly outside the
144 GAC;
145 <li>sn.exe cannot be used to sign,
146 nor verify, an assembly that contains
147 the "ECMA public key";
148 <li>sn.exe doesn't support all options
149 to turn on/off runtime verification
150 for some assemblies;
151 <li>StrongNameIdentityPermission
152 support isn't complete as it depends
153 on CAS.
154 </ul>
157 to sign assemblies (in fact any PE file) with
158 an Authenticode(r) compatible signature (with
159 or without a timestamp) using the security
160 tools cert2spc.exe and signcode.exe. We also
161 have support to test this using the tools
162 makecert.exe, chktrust.exe and setreg.exe.
163 What we are lacking:
164 <ul>
166 chaining is very limited and we do
167 not support certificate revocation
168 in anyway;
169 <li>Not every options are implemented
170 in all tools (and some do not really
171 apply to Mono);
172 <li>PublisherIdentityPermission
173 support isn't complete as it depends
174 on CAS.
175 </ul>
177 <li>ASP.NET caching: Non-existant at this point, this
178 needs to be implemented.
180 <li>Stability of ASP.NET and Mod_Mono. They are both
181 functional, but they fail under load. Much debugging
182 and testing must go into these components. As we use
183 more of it, we have found more little problems surface
184 on it.
186 <li>Codebase audit: Duncan did an audit of Corlib, but
187 we must do an audit of all the assemblies that we we
188 are going to ship, just to get an idea of the major
189 areas missing.
190 </ul>
192 <p>The team at Novell will focus on these areas. We of course
193 welcomes the contribution of the rest of the Mono team and
194 encourage the developers to focus on 1.0, to have a solid
195 release, and a solid foundation that can lead to 1.2
197 <p>We will use Bugzilla milestones to track these issues.
202 a preview of Monodoc with the early documentation.
206 <p>Various Mono developers are working on areas that will not
207 make it into the 1.0 timeframe: JScript, WSE, VB.NET,
208 Windows.Forms, Generics. We should continue to work on
209 those components, as they will come shortly after, and they
210 are probably more fun to develop than stabilizing the core.
214 <p>Everyone is probably very excited about the new features in
215 the Whidbey release of .NET, and most importantly the Longhorn
216 features. I am sure that many of us will not resist the urge
217 to put some of the new assemblies on CVS.
219 <p>We will likely add a profile for those of you that want to
220 work on this, and can not wait to get your hands in the code,
221 although keep in mind that your contributions wont reach the
222 general audience until we successfully ship 1.0.
224 <p>The things to keep in mind while adding code which is not
227 <ul>
228 <li>Make sure you surround new classes and methods
229 with the appropriate define: NET_1_2 for things
230 available on the .NET 1.2 SDK (Whidbey) and NET_3
231 define for things only available on the Longhorn API.
232 We need this so that these methods do not appear on
235 <li>If you add generic types or methods, also surround
236 the method with GENERICS for now, since our compiler
237 can not currently build this code yet. This is
238 redundant with the NET_1_2 define but important.
240 <li>For every assembly you update, make sure that you
241 also add the relevant AssemblyInfo versioning
242 information. If possible, when you add methods from
243 .NET 1.2 to the build, also update the AssemblyInfo.cs
244 for the library.
245 </ul>
247 <p>There are three areas of new hot features:
249 <ul>
251 time frames).
256 <li>Avalon: Definitely a Longhorn-bound feature.
257 </ul>
259 <p>Most code that will reach the users in the short time frame
260 (next year) will be related to the Whidbey improvements, so I
261 encourage developers to work on those pieces, as they are the
262 ones that will help Mono the most.
266 <p>Gonzalo will continue to coordinate this effort; At this
271 <p>On the surface Avalon seems like it uses something like
272 GdiPlus/Cairo for rendering. That was my initial feeling, but
273 it turns out that they had to rewrite everything to have a
274 performing rendering engine, and implement some very advanced
275 rendering features that include compositing with video
276 streams, also their brushes seem to be fairly powerful.
278 <p>XAML, a new markup language that binds tags to .NET classes
279 was also presented, but this is the least interesting part. A
280 tiny compiler translates the XAML source files into C# code.
281 The whole process is just like Glade, and should be easy to
282 do.
284 <p>The really elaborate parts are the rendering engine, and the
285 composition model for widgets. It is a complete new toolkit,
286 and if we want to implement this one, we will have to have a
287 new toolkit on Unix, incompatible with everything else, maybe
288 stressing the importance of working with other open source
289 projects in defining a cross-toolkit theming strategy to
290 address this particular problem.
292 <p>A Mini-Avalon is easy to do, but a complete one will
293 require much interaction with other groups: the Cairo folks
294 are probably the most qualified to assist us.
299 href="http://msdn.microsoft.com/Longhorn/understanding/pillars/Indigo/default.aspx?pull=/library/en-us/dnlong/html/indigofaq1.asp">FAQ</a>),
300 but it could benefit from continued development of our WSE1
301 and WSE2 components, later to bring some of the code to it.
303 <p>Again, since people are visibly excited about this
304 technology, we will lay down in the next few days a framework
305 to contribute to it.
308 <p>
311 </body>
312 </html>