Re: Time to heat up the new module discussion

[Darren Kenny <Darren Kenny Sun COM>]

Iain * wrote:
> 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? 

:)

In a way, yes - if we didn't have the original GNOME desktop and libraries
written in C we could have had so many language bindings in the first place? How
many language bindings exist for KDE that didn't first have to present a C API
to enable the binding...

It's important to make the right decisions to enable maximum volume - Mozilla
uses C++, but in a VERY limited and strict way - this is enable it to be
compiled by the majority of C++ compilers on the market and still be compatible.

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

You are comparing "prototyping" with product ready code - again I bring up the
"how many good MS Windows apps are written in VB" - you'll find many did the UI
first in VB first - to prototype it - an then changed to a MFC/C++ for the final
implementations...

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

Yes, but there is a Core Desktop - I think we need a definition of this - could
you consider a desktop running without metacity or gnome-panel or gnome-session
as GNOME - I wouldn't think so. Applets are fairly core here - most people need
the taskbar, the notification area, the date/time, the volume control, etc. -
without these the desktop isn't very GNOME like, is it?

If you aren't interested in a language split, then I think we should at least
have a Core GNOME Desktop definition.

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

True - it sucks for many things - but it has it's strengths too - the main one
on Unix being that it's core to the whole platform, most languages support
binding to it, usually right out of the box because of this...


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

It only is if we can be sure that the Core Desktop isn't being overrun with
non-C elements - once we start to move outside that box the choice becomes less
and less and disabling things means you have very little functionality (and
possibly usability) remaining.

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

OK... But I'm sure this was also important in the multi-user context since you
can be sure there will be a Vista Server version too...

Darren.

> 
> iain