Re: Putting the 'Mono debate' back on the rails

[Miguel de Icaza <miguel ximian com>]

Hello,

> Miguel wrote: "I would be interested in understanding what the issues of 
> non-splitting are, from the GNOME point of view."
> 
> For one, if in the future Gnome would like to provide an embedded version 
> (there was some talk about it already), it would be easier to pick and 
> choose components as seen fit. In a 64 MB firmware you can't  fit 
> everything, usually... Of course, I don't think that this means that you 
> need 3 different tarballs instead of 1. As long the selective functionality 
> is present in your current tarball (via an autoconf option), I don't see why 
> it should be physically split in different tarballs. But some form of 
> seperation must exist as the rest of the Gnome is very modular in its 
> nature.

Nothing is stopping embedded developers from just shipping the libraries
from Gtk# that they need, they do not need to ship everything that the
tarball contains.

In addition, you might not even need a full binding of Gtk# or any of
the component libraries, or even the Mono components in an embedded
deployment, you might just need a subset.

This is in fact, one of the problems with the Compact Framework from
Microsoft.  Someone decided "This is what we will support on an embedded
system" with no consideration for the fact that embedded systems are
hardly the same, and the kinds of applications are always different (the
guys screwed by Microsoft are some of our major users: they copy-paste
Mono's class library code so they can get features that Microsoft left
out).

The right approach is to use a tool that can take a library, and using a
specification that contains the features required it produces a "light"
version of this library.   

There are commercial tools that do this for CIL libraries, we have our
own `monodiet' which is being replaced with a simpler and more complete
`CIL Linker' based on the Cecil libraries.

Miguel