web/mono-hacking-roadmap.html

   1 <html>
   2 <head><title>Mono Hacking Roadmap</title>
   3 <style type="text/css">
   4 h1 {
   5 color: #efefef;
   6 font-size: 18pt;
   7 font-family: "Trebuchet MS";
   8 border: 0;
   9 margin: 0;
  10 padding: 1em;
  11 background: #666666;
  12 }
  13
  14 h2, h3, h4, h5, h6 {
  15 font-family: Verdana,sans-serif;
  16 font-weight: bold;
  17 margin: 9pt;
  18 }
  19
  20 h2, h3 {
  21 font-size: 18px;
  22 }
  23
  24 h2 {
  25 padding: 3px;
  26 color: #000000;
  27 }
  28
  29 h3 {
  30 font-size: 13px;
  31 border-bottom: 2px solid #dddddd;
  32 }
  33
  34 h4 {
  35 border-bottom: 2px solid #dddddd;
  36 }
  37
  38 body, table {
  39 background-color: #ffffff;
  40 font-family: Verdana, sans-serif; font-size: 12px;
  41 color: black;
  42 margin: 0;
  43 padding: 0;
  44 border: 0;
  45        margin-left: 20%;
  46        margin-right: 20%;
  47 }
  48
  49 p {
  50 margin-left: 2em;
  51 margin-right: 2em;
  52 }
  53
  54 ul li {
  55 margin-left: 2em;
  56 }
  57
  58 img {
  59 border: 0;
  60 vertical-align: top;
  61 }
  62
  63 </style>
  64 </head>
  65 <body>
  66 <center>
  67   <h1>
  68   Mono Hacking Roadmap
  69   <br>
  70
  71   <font size=1>Miguel de Icaza (<a href="mailto:miguel@ximian.com">miguel@ximian.com</a>)</font>
  72
  73   </h1>
  74   <p>
  75 </center>
  76
  77 <h3>Introductory notes</h3>
  78
  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.
  84
  85 <h3>Background</h3>
  86
  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
  93         the public.
  94
  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
  99         another year .  The <a
 100         href="http://www.go-mono.com/mono-roadmap.html">Mono
 101         Roadmap</a> emphasizes this assumption.
 102
 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
 106         use.
 107
 108 <h3>Mono 1.0: missing functionality.</h3>
 109
 110         <p>For the 1.0 release, there are a number of features that we
 111         will have to complete, in no particular order:
 112
 113         <ul>
 114                 <li>We need to fix corcompare and our cor-compare
 115                 pages to support both 1.0 and 1.1 API API compares.
 116
 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.
 122
 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.
 126
 127                 <li>PowerPC port.
 128
 129                 <li>ECMA profile: We will like take care of this one
 130                 at Novell.
 131
 132                 <li>Assembly signing: There are two ways to sign
 133                 assemblies.<br>
 134
 135                         <b>StrongNames</b> - It is possible to sign
 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>
 155
 156                         <b>Authenticode</b> - It is possible today
 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>
 165                                 <li>Currently our X.509 certificate
 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>
 176
 177                 <li>ASP.NET caching: Non-existant at this point, this
 178                 needs to be implemented.
 179
 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.
 185
 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>
 191
 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
 196
 197         <p>We will use Bugzilla milestones to track these issues.
 198
 199 <h3>Synchronized releases</h3>
 200
 201         <p>It would be great if we can ship Mono 1.0 with Gtk# 1.0 and
 202         a preview of Monodoc with the early documentation.
 203
 204 <h3>Alpha components.</h3>
 205
 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.
 211
 212 <h3>New components: Whidbey and Longhorn features</h3>
 213
 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.
 218
 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.
 223
 224         <p>The things to keep in mind while adding code which is not
 225         in .NET 1.0 and .NET 1.1:
 226
 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
 233                 the 1.0 and 1.1 builds.
 234
 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.
 239
 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>
 246
 247         <p>There are three areas of new hot features:
 248
 249         <ul>
 250                 <li>Class library improvements (Whidbey, Mono 1.2
 251                 time frames).
 252
 253                 <li>Indigo: They will release this in 2005 or 2006 and
 254                  wont make it into the 2004 Whidbey .NET 1.2 release.
 255
 256                 <li>Avalon: Definitely a Longhorn-bound feature.
 257         </ul>
 258
 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.
 263
 264 <h3>ASP.NET 2.0 plans</h3>
 265
 266         <p>Gonzalo will continue to coordinate this effort;  At this
 267         time ASP.NET 2.0 features will not make it into Mono 1.0.
 268
 269 <h3>Avalon plans</h3>
 270
 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.
 277
 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.
 283
 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.
 291
 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.
 295
 296 <h3>Indigo Plans</h3>
 297
 298         <p>Indigo is still an early product (<a
 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.
 302
 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.
 306
 307
 308 <p>
 309 <i>Last Updated: Nov 1st, 2003</i>
 310
 311 </body>
 312 </html>