Re: Time to heat up the new module discussion

[Darren Kenny <Darren Kenny Sun COM>]

Iain * wrote:
> On 7/12/06, Darren Kenny <Darren Kenny sun com> wrote:
> 
>> I'm concerned about the inclusion of GTK# - and hence all the rest of Mono into
>> the core GNOME.
> 
> It doesn't pull mono into the core of gnome anymore than having python
> applets pulls python in.

You are correct, it doesn't but that doesn't make it right - I'm not that happy
about Python being in the core desktop which is why I mentioned about breaking
things up into Core GNOME and others.

> 
>> And it worries me that this is opening a door for a slew of C# based
>> applications into the core GNOME.
> 
> And this is a bad thing because...?

I'm not totally against C# applications themselves - what I am for is choice. I
don't think any thing other than C should  be part of Core GNOME - to put
anything other than C into here can cause loads of problems - what happens if we
start to do all our main development in C# (or anything else for that matter)
going forward, then less and less of GNOME will be re-usable without Mono since
all the innovation will be in C#. This is why I think we need a definition of
what is core...

An example that effected us in Sun recently is Avahi - Avahi is excellent work
and a good implementation of the Zeroconf networking stack - but it is very high
level and has a dependency on D-Bus - so to implement something to support it's
use in the nsswitch.conf file (that maps gethostent calls to files/dns/nis/ldap
in a transparent way) we would have to include dependencies on LOADS of, what
would be generally considered application layer APIs, in to an area that it
simply wouldn't make sense (libnss tends to be VERY low down the stack in
regards to APIs that people use). D-Bus in turn has a Python dependency - now
while I know this is optional - it makes for a difficult argument as to how to
package it, etc.

Now while there are ways to combat this - it's a prime example of where there is
a severe overlap in things, and where it makes sense for projects to be broken
in to core and non-core elements so that it's clear how to break things up if
needed into the parts that simply can't be done without and the parts that are
optional - configure is fine for some cases, but it doesn't make it easy to
deliver things when a customer decides that they want the zero-conf networking
without a desktop platform (CDE/KDE/GNOME) installed.


> 
>> It makes sense to me that Mono should remain on the out-skirts of GNOME for this
>> very reason - core GNOME should only use native languages, and more specifically
>> C, as to to do otherwise is likely to effect the already perceived poor
>> performance of GNOME.
> 
> Python is already used in the deskbar applet which is in core GNOME.

So? Again, this is where it shouldn't be - it should be in the Python GNOME area...

> 
>> Just think about what happens when a user logs into a desktop that has Python
>> and C# based applets included with C based applets:
>> - The panel starts
>>   - It starts C/Bonobo based applets - the smallest of which already consumes
>>     approx 40Mb of memory.
>>   - It starts Python applets - each of these takes up approx 70Mb of memory -
>>     and very little of this is shared
>>   - It starts a C# based applet - and this pulls in Mono, which I'm sure isn't
>>     that small, but I guess at least it does share memory better than Python,
>>     but there is still quite a lot of additional memory pulled in.
> 
> Then...umm, don't run them?

That sounds fine, but if we keep developing things in something other than C,
which are more than just prototypes, then there won't be much choice left, will
there?

> 
>> I know today people say that memory is cheap, but I think that's not an excuse
>> for working on reducing it's consumption.
> 
> Limiting memory usage by limiting features is kinda a pyrrhic victory.
> "Well, yes, we only have one button on screen, but damn we don't use
> any memory"

Maybe on a single machine, but we, in Sun here also have to seriously consider
the multi-seat machine (like Sun Ray), and I'm sure other commercial companies
would be interested here too. So running lots of copies of applications that
have their own platform, with their own "busy" idle loops (garbage collection)
and so on, it becomes a major issue when there are 100 users on the one machine
fighting for that tiny slice of time they might get to do some processing.

> 
>> Also, there is the small devices like
>> the Nokia 770 for which memory consumption is a big factor.
> 
> As far as I know, no-one is attempting to run the gnome panel and
> python/mono applets on a 770.

Yes, but if we keep developing things which are being considered major pieces of
functionality in something other than C, these devices will have to invest
serious effort in writing their own alternative that could be. The whole point
of these devices using GNOME is to be able to provide some of the core GNOME
apps on a small device, otherwise they may as well be using their own toolkit
and ignore GNOME - which I think is exactly what we wouldn't want to happen
since the use of things like GNOME in small devices serves the help GNOME
improve performance greatly on large devices :)

> 
>> As for .NET, even Microsoft themselves had to pull back from using it for core
>> functionality due to performance reasons - why do we think we will do any better?
> 
> As someone who is running mono based applications fairly regularly, I
> haven't noticed any major performance issues. We're not talking here
> about replacing the core libraries with c# based ones, we're talking
> about applications, and for me the mono based apps are just as fast as
> the C based ones.

Again, you're probably one user on one machine - we need to "think out side of
the box on your desk".

Darren.
> 
> iain
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list