1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
|
<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>
|
