In a recent interview Anders said:

If you ask beginning programmers to write a calendar control, they often think to themselves, "Oh, I'm going to write the world's best calendar control! It's going to be polymorphic with respect to the kind of calendar. It will have displayers, and mungers, and this, that, and the other." They need to ship a calendar application in two months. They put all this infrastructure into place in the control, and then spend two days writing a crappy calendar application on top of it. They'll think, "In the next version of the application, I'm going to do so much more."

Once they start thinking about how they're actually going to implement all of these other concretizations of their abstract design, however, it turns out that their design is completely wrong. And now they've painted themself into a corner, and they have to throw the whole thing out. I have seen that over and over. I'm a strong believer in being minimalistic. Unless you actually are going to solve the general problem, don't try and put in place a framework for solving a specific one, because you don't know what that framework should look like. [Artima's interview with Anders]

I like Anders' position regarding Checked Exceptions, contrast this with James Gosling's statement, which I believe does paint a broken picture:

One of the traditional things to screw up in C code is opening a data file to read. It's semi-traditional in the C world to not check the return code, because you just know the file is there, right? So you just open the file and you read it. But someday months from now when your program is in deployment, some system administrator reconfigures files, and the file ends up in the wrong place. Your program goes to open the file. It's not there, and the open call returns you an error code that you never check. You take this file descriptor and slap it into your file descriptor variable. The value happens to be -1, which isn't very useful as a file descriptor, but it's still an integer, right? So you're still happily calling reads. And as far as you can tell, the world is all rosy, except the data just isn't there. [Artima's interview with James Gosling]

This is in fact the source of many security problems. One of the first security code audits I witnessed was by a volunteer that reviewed my first setuid application that I shipped as part of the Midnight Commander (the software only shipped after the security audit). A 200 line program got back 700 lines worth of comments, many of them related to not checking error conditions from trivial system calls like `close()'.

But modern C APIs do not use int return codes, in fact not even the C standard library uses those: that is only the low-level Unix C API that has this feature. The standard C library API returns a FILE * object, and for instance, most of Gtk+ and Gnome APIs return objects (in the form of a pointer to an object).

The beauty of returning a pointer to an object, is that you can return NULL as your standard error return value, and if the value mattered, you will most likely take the necessary steps to check its return value, or they application will just crash the moment you try to use it.

This could be applied to the .NET and Java APIs to reduce the amount of required try/catchs. For example, the File.IO.OpenRead method could be (shown here is the artist's representation):

	public static FileStream OpenRead (string file)
	{
		int fd = open (file);
		
		if (f == -1)
			return null;
		return new FileStreamFromFD (f);
	}

Which makes null a valid return value. If you fail to check for the return value, you would get a nice NullReferenceException, but you would allow the expensive creation of an exception object, and the ugly try/catch block in the call site.

Obviously we can not change the existing APIs, but we could encourage developers to minimize their use of exceptions. In my limited personal experience with software design, when I have faced applications with tons of Exceptions it was extremely hard to keep up with them. A rewrite of the software to avoid exceptions and use the more sane API paid for.

More Mono Bloggers

I wrote about Ben previously, he now has a blog which we are hosting for him at Ximian.

Laura and myself have been shopping for various items for our new appartment. Once we had chosen the rug, everything fell into place, and in two hours we swiftly sorted out our color differences. The rug really ties the room together.

New Mono Bloggers

Just coming back from the HispaLinux congress in Madrid. This was a very short trip: only two days in Madrid, traveled all this and did not have enough time to eat enough ham.

Update on Extremadura from Jose: they are 100,000 Linux desktop machines in the administration and 276 machines on public centers. The public machines are fewer than the 1,500 from the Telecentros, but still a healthy number.

Try Ximian Desktop 2

The fine folks in Spain have a Live CD with Ximian Desktop 2. You can try Ximian Desktop without installing Linux on your machine, the whole system runs from a CD.

OpenOffice gets .NET support

Federico pointed me to the announcement of OpenOffice's support for C# and the CLI, it is here:

We are pleased to provide a preview of the CLI-UNO language binding. It gives developers the possibility to write client programs for OpenOffice.org, as well as stand-alone UNO applications, with CLI languages, such as C# and VB.NET.

The details about the language binding are here: http://udk.openoffice.org/cli/cli-uno.html.

PDC

The Microsoft PDC program is getting more and more interesting. As a sneak preview of the table of contents of a System.Xml/System.Data based book shows. Dare also sent me a link to the ASP.NET changes. Fantastic!

Lluis, the developer behind Mono's XML Serialization, a large part of Remoting and our SOAP web services stack has started a blog. His first post is about the his GenXS tool used to create custom XmlSerializers (a feature not found on Microsoft's edition, but that we use in a few places).

Dare linked to Omri's posting about why binary serialization for XML is a bad idea.

I have not really formed an opinion, and am definitely not an expert on the matter of binary serialization for XML, but I believe that Omri's position is an incorrect one. Omri's thesis is that there are multiple things that you might want to opmize for: size, parsing speed and overhead for generating the data and that it is not possible to define a file format that satisfies all of those different needs.

This is not new, and this happens with everything we build today: as software developers we constantly have to balance multiple needs: maintainability, performance, extensibility, perfection, scalability, configurability, usability. The job of an architect is precisely to find a good balance taking input from multiple sources. We are going to make mistakes, every step of the way, but the sooner we start making those mistakes, the earlier we will be able to collect real data on the issues at hand.

The other problem with Omri's thesis is that it misses one bit: who are those likely to benefit from a binary format? They probably will fall in two camps: those who want smaller chunks of data transfered, and those who want faster encoding/decoding of the infoset not the average XML user.

We do not need to satisfy everyone, just a large percentage of the user base. The others can feel free to define a different format, or ignore this solution altogether or build on top of this in the future.

For instance TCP/IP makes no guarantees on quality of service despite the fact that many people have valid and important uses for it. Still, it did serve a large community of people and what is even more interesting: clever people found ways to work with these limitations and do a reasonable job given the foundation.

Some time ago, I spoke to Daniel Veillard the author of Libxslt and Libxml. When Mono started, we wanted to reuse as code as possible, and those two libraries made a lot of sense to reuse.

The problem is that .NET Framework defines three mechanism for handling Xml: the Dom model, the pull parser, and the path navigator (a DOM-like interface). It was not possible for us to just use libxml to implement our Xml needs, it would have added too much overhead, and would have been an ugly hack.

.NET contains two pretty clever tricks: the pull parser (XmlTextReader and XmlTextWriter) and the path navigator, which exposes a cursor-based navigation interface. The beauty of the interface is that you can wrap any kind of data source and expose it to the XML subsystem with this interface. So you can wrap a database, a comma separated value file, a file system, anything you can think of, and dynamically provide the content. Interesting because it is possible to use XPath queries on top of it, or apply xslt transformations. XSLT in .NET is built completely on top of the XPathNavigator.

For a long time, in Mono we used libxslt: we would dump all the data from an XmlDocument, or a XPathNavigator into a temporary file, and then use libxslt to do the heavy lifting.

This approach had various problems: libxslt was not designed to be thread safe (a requirement for us: on ASP.NET we need to be able to do xslt transformations from multiple threads), so we had to add big locks around the xslt invocations. Also, it was not possible to create a context for the transformation, so extension functions were global to all the transformations. The only solution was to shutdown and restart the libxslt engine every time we did a transformation, not really optimal.

Fixing the problem was not going to be easy. Libxslt is a very large piece of code, and Daniel estimated that re-implementing it would take about a year. That is why I discouraged 16-year old Mono developer Ben Maurer from working on this project. He was not really ready to spend a year of hairy coding, and would likely not be able to do something even as fast as Libxslt.

Ben ignored my advise and went on to implement a managed implementation of XSLT. The idea was to remove the libxsl dependency: remove the temporary files, fix the extension object problem, and the locks.

In the course of a couple of weeks this summer, Ben had the basics of XSLT done, and he recruited the help of Atsushi to help with problems and missing features in the XML core, and Piers to fix and improve our XPath implementation.

The three hacker team in less than a month did a tremendous amount of progress implementation was able to be used instead of Libxslt for Monodoc.

The surprising news this week is that Ben has made Mono's managed XSLT faster than the C-based libxslt. Faster on a number of the XSLTMark tests and on other practical stylesheets (including the stylesheet used in Monodoc). The performance can be attributed partially to some performance improvements Atsushi did to our handling of XPathDocuments. The other part was the tireless work of Ben in doing performance tuning in our implementation: from profile-driven changes like removing calls to foreach on ArrayLists with loops to architectural changes. The biggest improvement was adding an interface for resolving functions/variables at compile time.

Atsushi mentioned that lots of the performance improvements came from Ben reusing concepts from SAXON. SAXON is the fastest xslt implementation out there, and its written in Java.

Congratulations to all the Mono XML crazy hackers for achieving this fantastic progress in so little time.

Oberon in Mono

The Mono IL assembler has finally matured to the point where it can be used to bootstrap the Oberon IL compiler on Mono. The details are in Jackson's Blog.

Of course, some of you might want to laugh because we got generics support before Oberon worked ;-)

Go Jackson!

Jakarta and Mono

Anne talks about our recent discussion. She wants to reuse the Mono CLI, and build on top of it patent-free technologies along the lines of the technologies done in the past for Java (Cocoon, Struts).

She is absolutely right about the need to build a parallel universe of technologies. In Mono we have already started this process:

Jonathan Pryor has written a tutorial about Marshaling on Mono and the .NET Framework. Hopefully this will become a chapter on the Mono Handbook

One of the points discussed on the document is about string marshalling in .NET and the limitation imposed by the current specification. Sadly the ECMA specification (and .NET) only cover Ansi and Unicode as encodings for strings. Both are also underspecified, they are both `platform independent encodings'.

This is a problem, because there is no such thing as `Unicode encoding'. There are specific ways of encoding: utf-8, utf-16, ucs-2, ucs-4 and others. Which one are we talking about.

The issue we face on Unix and Windows is that there are plenty of libraries that have very specific requirements. We first ran into this problem with the Python bindings to .NET. Python can be compiled to either use utf-8 or ucs-4 API entry points.

Another example is Gtk#. Currently it generates bindings like this:

[DllImport("libgtk-win32-2.0-0.dll")]
static extern void gtk_label_set_text(IntPtr raw, string str);

public string Text { 
	set {
		gtk_label_set_text(Handle, value);
	}
}		
	

The above uses the default "Ansi" encoding, which we have conveniently mapped in Mono to do a conversion from Unicode to utf-8 (Gtk+ uses utf-8 as input). But this is not entirely correct. The trouble is that to be entirely correct we will have to generate code like this:

[DllImport("libgtk-win32-2.0-0.dll")]
static extern void gtk_label_set_text(IntPtr raw, IntPtr str);

public string Text { 
	set {
		// Marshaller is a helper class that every developer
		// has to roll on its own.
                IntPtr raw_str = Marshaller.ConvertToUTF8 (value);
		gtk_label_set_text(Handle, raw_str);
		Marshaller.PtrToStringGFree (raw_str);
	}
}		
	

This is not a problem for Gtk# which is generating the bindings for us, just a bit more of annoyance, but it is a problem for newcomers to .NET who will find the above just too complicated for average use. Not only that, but the other problem is that most of the time the app appears to work. It is only under stress conditions found during deployment (or testing if you are lucky) that the developer will be bit by this missing functionality.

We identified a couple of unused bits on the encoding for this attribute in the ECMA spec, and suggested that they get used for the most populate encodings (utf-8 and ucs-2 I believe), but we were turned down by Microsoft. The current position is to use a platform specific attribute to encode this. This has problems, because we can not be compatible with .NET unless we all adopt the same scheme. The other problem is that by using a real custom attribute to do this, as opposed to a synthesized one (the attribute being turned into a bit value) is that we will loose performance.

Anyways, too bad that Microsoft is not interested in fixing this platform usability issue, specially since they have been focusing on fixing things that would force programmers to write more code. This seems like one of those things.

Plenty of us the Mono developers and Linux developer got together during the Brainshare event in Barcelona. Lluis (the man behind the implementation of Mono's Remoting and Mono's WebServices support) lives in Barcelona, and Gonzalo (Mono's ASP.NET developer) was coming back from vacation from Istambul. It was the perfect chance to discuss Mono.

Juantom�s (HispaLinux's president) joined us on Monday night, and Man, Andreu and Osorio showed up on Tuesday for a few hours for dinner. We had a great time with both our new co-workers are Novell and the Spanish Linux crowd in Barcelona.

Jordi Mas who has been working on Abiword and on the catalonian support for various free software projects is developing an interest for Mono. He has plenty of Win32 experience, and he is interested in helping us move Mono's Windows.Forms support forward. He advocates following a single path: Wine-based Windows.Forms and customizations to Wine to make it track the Gtk+ theme and dropping our support for the Gtk+ based toolkit.

Spent a fair amount of time with Nat: mostly at night when tracking the best restaurants that served jam�n and the bars afterwards. Nat had a little accident with his new cell phone.

Novell

One of the benefits of joining Novell for us was that our products have a much bigger audience now. This is due to the fantastic channel that Novell has with enterprises. During the conference we met many sales and solution engineers of Novell, many of them already with contacts of people interested in Linux-based solutions (both the Novell Linux software stack for servers as well as the desktop side).

Plenty of people at the confere are considering Linux on the desktop, a recurrent topic with people we met on the hallways was large scale enterprise deployments.

XD2 has the right mix of components to make the Linux Desktop on enterprises a reality:

• GNOME 2.4 has been making tremendous progress in terms of accessibility, ease-of-use, simplicity, API stability and the Gnome Foundation who has helped focus the development on these important projects.
• OpenOffice is maturing, and we are commited to keep improving the common code base on which OpenOffice is built to help people migrate and reduce their costs of deployment.
• Mozilla: a fantastic standards compliant browser. My favorite feature today: tabbed browsing, the smartbar plugin.
• Red Carpet: A recurrent theme we hear about people doing large desktop deployments is that they need a way of managing these machines. Red Carpet does a lot today, and the management roadmap is at the center of the development effort right now.
• Evolution: Mail, calendar and addressbook, with groupware collaboration.

Nat did one of the most amazing presentations I have ever seen on why the above software stack is the right one for Linux on the desktop.

We are collaborating with other teams inside Novell to support the Novell software stack: Groupwise, i-Folder, e-Directory and Liberty Aliance authentication

More Gnome Deployments

In Andaluc�a, 20,000 Gnome desktops were just launched. I have to take a trip there to witness this again. 20,000 Gnome-based machines on 1,800 schools in Andalucia. I have to go see this. Congrats Gnome folks!

The Telecentros experience in Sao Paolo was very interesting, because the site I went to was one of the centros equipped with accessibility hardware.

Yesterday I arrived to Barcelona for the Novell Brainshare event.

Got together with Chema, Lluis and Nat. Went relatively early back to the hotel, and discovered that we had wireless access, so we hung around until 4am. Nat's humor quality is directly proportional to how long he has gone without sleeping.

Monodoc editing

In our effort to improve the documentation in Mono we have been working on a GUI tool to browse all kinds of documentation (Monodoc), but we need more people documenting our APIs.

To address this problem, we are making it really simple for people to contribute documentation: we have made our documentation editable. When you are viewing a stub, you have the choice to edit it; For example:

Summary
        To be added [Edit]

I recently added a preview viewer for it, for example here we are editing some documentation:

All those changes are saved into a changeset, that the contributor can submit when he is ready. We will submit those using Mono's web services infrastructure. When the changes are reviewed and approved, we commit those to CVS, and they appear on the next release of the code.

This same infrastructure will help for our collaborative annotations for the documentation. This is important to have people share their personal experiences and samples for any given API.

What I really like about blogs is that sometimes people sit down, and write little essays reflecting on their experience. My personal choice is from the craftsmen: because they tell you tales and lesson from the trenches.

I can not make justice to the beauty of Eric's latest entry: F5.

While doing my daily reading of the SWT-port-to-C# reading this morning, found this post that describes the torrid story of Swing and SWT.

Update: That document contains various errors on the side of the origins of Swing. For more details see this thread.

Amy describes her experiences with the iPod and a native user interface here. Very good point about using native interfaces. Firebird already has a couple of XUL-based clients that let the user browse Amazon more comfortably than using the regular Web interface.

Al Franken's book

I have been reading Al Franken's Lies book. It has been entertaining for the past couple of days, but it turned out really interesting on the chapter on the Clinton efforts on the war against terror and how the Bush administration dropped the ball on that (chapter 15, but it shines on chapter 16).

I tried writting a summary, but its impossible to make justice to those two chapters. It is particularly interesting, because Franken got a team of Harvard graduates from the Kennedy school to fact-check everything he wrote.

Anyways: mandatory reading if you stop by a book store.

Cant wait

To see The Band on the Runtime perform

I am using a new IBM T40 now as my main computer. I was about to go for the X31 which is lighter and smaller, but I have gotten used to the large resolution from my old T30.

Michael Zucchi provided me with a few links to people running Linux on the T40. Most hardware is supported on the T40, but the speed of the hard drive left much to be desired. The new T40 felt like it could not handle the load the T30 did. Any IO would make the system very slow.

After dropping by the #kernel channel on LinuxNet, I was told to upgrade my Kernel to the latest RH update. So far the speed of my hard drive went from 2.5 MB/second to 25 Mb/second. An e-mail expunge that used to take about two minutes seconds, now takes 13 seconds.

I am going to the PDC, hoping to listen to Don's new single.

Gonzalo and Lluis from the Mono team are coming as well.

Also found the PDC Bloggers site.

Moving day

A completely unproductive day. I just moved into my new apartment, where I will be Nat's neighbor.

Verizon cancelled my DSL during the move, and am using a kind soul's wireless access.