diff options
Diffstat (limited to 'web/mono-hacking-roadmap.html')
| -rw-r--r-- | web/mono-hacking-roadmap.html | 312 |
1 files changed, 312 insertions, 0 deletions
diff --git a/web/mono-hacking-roadmap.html b/web/mono-hacking-roadmap.html new file mode 100644 index 00000000000..134a1d42541 --- /dev/null +++ b/web/mono-hacking-roadmap.html @@ -0,0 +1,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> |