Re: Time to heat up the new module discussion

["Iain *" <iaingnome gmail com>]

On 7/14/06, Darren Kenny <Darren Kenny sun com> wrote:

> >> 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 -

So, by limiting choice you are attempting to promote choice?

> 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#.

All the innovation is in C# (and python...)
- Gimmie
- Deskbar
- Tomboy
- Banshee/Muine
- Jokosher

Compare the speed that Jokosher has progressed in 4 months with the
length of time its taken me to get Marlin anywhere (about 4 years, on
and off). Yes, they have different aims and Jokosher has more people
and isn't as advanced, but I think its interesting. In fact I have
been tempted to rewrite Marlin in C#, but we'll see.

> 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.

It doesn't anymore, the bindings have been moved out, but, this is a
minor packaging issue, which as far as I can tell, both ubuntu and
maemo have managed to solve, so I'd imagine the people at Sun can do
as well.

> > 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...

Maybe you're missing the meanings here...
There are two current splits
- platform
- desktop

Platform is the libraries and these are in C. Only C and don't think
that is changing anytime soon.

Desktop is applications and some other libraries.

Platform is "core" the stuff you can't do without

Desktop is optional, you can install bits of it and not install other
bits. We're talking here about putting stuff into the Desktop
platform. I don't see what advantage splitting things anymore would
do. If people want application XYZ then they have to install
application XYZ. If it has dependancies they don't like, then they
don't get to use application XYZ.

> 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?

Thats life...if we limit stuff to C then we're not going to get
anywhere, because really, C sucks (and this is speaking as someone who
has coded in C for 13/14 years).

> 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.

So, yes, things need optimised and improved, no-one is arguing against
that. But, if that really is your worry, then don't install the
software you don't like. That is your choice ultimately.

> >> 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".

The claim was that "Microsoft themselves had to pull back from using
it for core functionality due to performance reasons". I don't imagine
those performance reasons were on multiuser application systems, so I
was responding within the same context.

iain