> Joe Shaw wrote:
> 
>>> It is a very different situation. While the power manager support 
>>> provides new functionality, GTK# would only provide duplicate 
>>> functionality for another development framework that overlaps with 
>>> GNOME.
>> 
>> Perhaps I am misunderstanding, but this argument doesn't make any sense
>> to me.
>> 
>> Gtk# isn't an application, so by itself it's not useful and doesn't 
>> really duplicate anything.  It does provide a native API to Gtk#, but
>> traditionally language bindings have been considered a strength of
>> GNOME.  Gtk# calls into Gtk+, so it's not like we have two competing
>> implementations of the toolkit here. I don't see the duplicate
>> functionality here.
> 
> My mistake, I didn't explain it correctly. What I meant was that the group
> of Gtk# plus Mono overlaps with a big chunk of the desktop. My 
> understanding is that GNOME is a development framework and Mono is another
> one completely unrelated. Both of them have quite big class libraries: XML
> parsers, string management, asynchronous I/O, etc.

There are some overlaps. However, I don't think we want to restrict GNOME to
unmanaged code for the end of time. The substantial resources spent by Sun,
Microsoft, and Novell on managed code for the desktop seem to suggest that
all think that this is the way of the future. Innovative applications have
been developed by using Mono that clearly would have taken much, much longer
without the help of this framework.
 
> Of course it is possible to use both of them for writing a single cool
> application, although it doesn't seem to be technically correct because of
> all the duplicate code: there would way too many unneeded possible failure
> points and wasted resources.

Mono will *not* be taking resources from the current GNOME community. Even
if there is on occasion, a but in Mono that needs to be fixed, it seems that
this is a net win given the increased development speed. I'm sure Joe Shaw,
Aaron Bockover, and Larry Ewing (among many others) would attest to the
benefit which Mono has provided as they developed applications. 

>> It makes increasingly less sense to write applications in C. If you look
>> at where the interesting and innovative development has been in terms of
>> applications in GNOME, virtually zero of them are C apps. They're all
>> either Python or Mono.  This isn't a coincidence.
> 
> For me the problem is not the language, but the addition framework.

So, given the choice of:

	- "virtually zero...interesting and innovative development" or
	- Two frameworks

You are suggesting less innovative development? There is absolutely nothing
suggesting that over the next 5 years, C applications will become easier to
develop. On the other hand, substantial improvements in managed languages
(such as generics, and the many enhancements coming in C# 3.0).

Also, it may become increasingly hard to attract new developers to GNOME
if we only support C. Most universities (including my own, CMU) focus their
cirriclum on managed languages.

> Does it make sense to you to use have three or four different DOM parsers
> in memory at the same time? (libxml2, python, mono and java for example).

First, java is not under consideration at this point. Let's not cloud the
discussion with off-topic issues. Currently, python and mono are where the
innovation that Joe has been talking about is happening.

This statement shows a clear misunderstanding of where the performance issues
are in todays desktop. Much of the memory that comes from loading multiple
frameworks is shared between processes. In addition, where framework bloat is
causing an issue in the GNOME desktop is in places that get loaded by 20 processes
(for example, GNOME-VFS). I can't imagine photo management, music playing, desktop
search, and desktop wiki-notes on a low memory computer -- in C, Mono or Python.

In all honesty, our biggest performance problem is coming from applications
that leak. This problem won't be made worse by Mono (in fact, I believe that
Mono's ease of development will help developers spend more time profiling).

-- Ben