1. The Mono project has certainly come a long way since the last time we talked, please tell us what were the major milestones you hit the last 8 months and what new features are the priority for the near future?
Miguel de Icaza: Most importantly the Mono community has grown tremendously: today 150 developers have CVS commit access to the Mono source code repository, and a lot of the community's effort has been focused in making Mono more reliable, more feature complete, and most importantly we have been doing work to make Mono a good development toolkit on Linux/Unix.
Mono would not be possible without the day-to-day work of hundreds of developers that make it happen. I suggest for those interested in a particular area in Mono, to check the ChangeLogs and the mailing list to identify the developer that has created this technology. Since Mono is a large community effort, I could not list the responsible developers on each section in the following answers as I would have liked to, because it would have taken me another week to reply.
There are of course major developments that have occurred in the past few months which are worth mentioning:
* Mono can now run ASP.NET web applications, we have demonstrated IBuySpy running with Mono, and we are polishing it every day to make it better and support more applications.
* The ADO.NET universe in Mono has matured quite a bit: not only we have the standard classes as found on the Microsoft .NET Framework, but we have added a number of providers ourselves, so we have a pretty good coverage for the databases available on Unix: Postgress, MySQL, SqlLite, Sybase, SQL server, Oracle, DB2, Odbc and more.
* Robustness and completeness: this is just a side effect of Mono being used on a day-to-day basis by developers.
* IKVM.NET support: IKVM is a Java Virtual Machine that runs on top of .NET. It essentially translates java classes into Common Intermediate Language (CIL) code at runtime, and uses the .NET/Mono JIT compiler to execute the code.
What this means is that it is possible to run Java applications on Mono. The IKVM.NET for example is able to run the IBM Eclipse IDE editor with the CIL runtime.
* A Debugger Framework: we started our debugger effort about eight months ago.
We have a set of classes to produce and consume debugging information. Today our compiler for example generates debugging information (which is conveniently stored as a resource withing the executable) and our runtime engine can use this information to produce stack traces that contain line information.
The debugger proper is written in C# with a little support library written in C for the low-level access routines, and it is relatively portable to various systems.
Mono requires a pretty featured debugger. The debugger supports multi-threaded application debugging, multi-language debugging as well as managed and unmanaged code debugging, including the debugging of the runtime and the JIT themselves.
The debugger is still being worked on and it is not ready for production use. Although the command line version is useful, most people will want to use the GUI version, and that will require some more usability work.
* Gtk# maturity: The Gtk bindings for Mono/.NET have reached a level of maturity that has enabled people to write various graphical applications with it.
For instance, our debugger and documentation browser are written with Gtk#.
Gtk# provides bindings to various libraries from the Gnome world, it is not limited to Gtk+, but includes support for Gnome, Libart, Rsvg, Atk, Pango, Glib and Gstreamer, with more features being added by the developers.
One nice extra of C#'s overloaded method mechanism is that we can have multiple routines with the same name, and we can afford to provide a simpler to use Gtk than the native C binding. Also accessors have been mapped to C# properties, and signals to C# events, so the binding reflects the .NET spirit. Other features include the attribute-based Glade support.
Since .NET allows applications to bundle various extra bits as "resources" of an executable or library, developers can ship a single binary that contains all the supporting data an application might need, as opposed to scattering images, glade files, resources and configuration files all over the file system.
Bindings for OpenGL and GtkMozEmbed (the Mozilla bindings for Gtk) exist as well.
* Documentation effort: A very important step has been undertaken to produce free documentation for the class libraries. Both .NET class libraries and the class libraries that we have produced in Mono or around Mono.
We have a documentation browser, and a documentation compiler. The documentation system is designed so multiple providers can be used, a feature that we will be using to integrate various kinds of documentation: ECMA XML documentations, C#-compiler generated documentation, our own HTML tutorial, C# language reference documentation, compiler reference, tools references and anything else that a developer would need to become productive on this environment.
A set of tools have been produce to maintain and track libraries as they evolve, a fundamental part of keeping our things documented.
* Remoting platform: various developers have stepped up and have implemented the remoting framework for .NET, a remarkably large task, as well as documenting the Binary formatter.
Remoting is a general purpose framework for building RPC systems that takes advantage of the .NET Framework's runtime introspection facilities to simplify the development of clients and server, and create stub-less and skeleton-less RPC endpoints.
* Apache integration: The System.Web classes can be hosted in any web server, and in particular a new Apache Module for Apache 2 does this. This is a frequently asked question.
Also, more and more commercial developers have been running their code on Mono, and we frequently get feedback on missing features or bugs in our implementation. With their help, the team has been addressing those issues, and making Mono a good choice for re-targeting their applications to Linux/Unix.
There are some missing components in Mono today though:
* System.Windows.Forms is still on its early development stages. Although some sample applications are starting to run, and the issues we had with the Wine integration have been sorted out, there is still a lot of work left to be done.
* EnterpriseServices and DirectoryServices are essentially non-existent today.
* Web Services: the client and server support is missing, although some of the infrastructure pieces they depend on have been implemented.
Regarding our future directions for Mono, we are aiming for feature completeness and robustness first, so far the team has done a great job here. We routinely bootstrap the Mono environment from scratch and run our regression test suites, but more would be of course welcomed.
We have been working on a new JIT engine that will replace the current engine. The objectives for the new engine are outlined here:
* Ahead-of-time compilation.
The idea is to allow developers to pre-compile their code to native code to reduce startup time, and reduce the working set that is used at runtime in the just-in-time compiler.
Although in Mono this has not been a visible problem, we wanted to pro-actively address this problem.
When an assembly (a Mono/.NET executable) is installed in the system, it would then be possible to pre-compile the code, and have the JIT compiler tune the generated code to the particular CPU on which the software is installed.
This is done in the Microsoft.NET world with a tool called ngen.exe
* Have a good platform for doing code optimizations.
The design called for a good architecture that would enable various levels of optimizations: some optimizations are better performed on high-level intermediate representations, some on medium-level and some at low-level representations.
Also it should be possible to conditionally turn these on or off. Some optimizations are too expensive to be used in just-in-time compilation scenarios, but these expensive optimizations can be turned on for ahead-of-time compilations or when using profile-guided optimizations on a subset of the executed methods.
* Reduce the effort required to port the Mono code generator to new architectures.
For Mono to gain wide adoption in the Unix world, it is necessary that the JIT engine works in most of today's commercial hardware platforms.
This new JIT engine should be released shortly, still working out on the release issues for it.
We are also tracking the new submissions of Microsoft to the ECMA group, and we will be publishing versions of our tools that provide the new features like Generics, anonymous methods, partial types and iterators.
Screenshots probably speak better, we have some at our site.