Re: Time to heat up the new module discussion

[Darren Kenny <Darren Kenny Sun COM>]

Chipzz,

This is exactly the way I feel about things.

Mono and Python etc are all very good in their own way, but I really don't see
why they need to be part of the core GNOME desktop - this was why I wanted to
break down the GNOME desktop into various groupings - so ISVs, etc. can make
their own mind up about what they wish to depend upon.

Someone mentioned that "everyone is already shipping Mono" - but that's not true
either - maybe many of the major Linux distros are - but what about others like
maemo, RedHat Enterprise Linux (don't know the plans on this in the future
though) and Solaris. There are too many legal risks with a full Mono platform -
some parts are fairly open, but there are others which are not - it's this
latter part that worries us here in Sun the most (at least that's my view on
things) - we're sick of fighting with MS and we don't want to give them yet
another reason for one ;)

Again - this is why I think there needs to be the choice to say "No" to mono -
it may be that we do consider doing something - but we certainly don't want to
be forced into it.

Darren.

Chipzz wrote:
> On Thu, 13 Jul 2006, Ben Maurer wrote:
> 
>>> On Thu, 2006-07-13 at 02:00, Ben Maurer wrote: [...]
>>>> In the long term, Mono can potentially reduce our performance problems.
>>> In the short term, there are performance problems and Mono will worsen
>>> them.
>> In the short term, Mono will deliver us applications many times more innovative than what we currently have. They might consume a bit more memory than what they would have if written in C. However, writing in them C would mean waiting much longer.
>>
>> If we can write the basic functionality faster, we have more time to spend on performance.
> 
> I think both the mono platform and the python languages are great plat-
> forms. I also think they have certain usages, but with certain restric-
> tions:
> 
> * Great platforms for ISV's to write applications. ISV's can specify mi-
>    nimal system requirements (both in terms of memory and in terms of
>    other platforms needed), and companies wishing to use those apps just
>    have to adapt to those requirements (they can buy whatever hardware is
>    needed, after all). We as gnome want our desktop to be usable on even
>    low-end hardware, like that old pentium 2 sitting in the corner.
> * Great way to *prototype* an application. I myself intend to write a
>    little app, but I would not want to impose python or mono restrictions
>    on possible users. Initial implementation will probably be in python,
>    but after the feature-set is complete it will be ported to C. The
>    point here is: the thing you want to get right first is the application
>    *logic* (how it behaves, the rules for interacting with the user). For
>    this purpose, languages like python and the mono platform are great.
> 
> 
> * The core of the desktop should be in C (or possibly C++). This includes
>    libraries, the panel, the core applets (like the clock, taskbar switch-
>    er), nautilus (and probably some others). The user with his old pentium
>    2, who just requires a basic desktop, should never have to use python
>    or mono.
> * Libraries should be in C no matter what. This excludes beagle for
>    example. Reason for this: anything other than C pulls in extra libs,
>    like libstdc++ etc, which make other language bindings a pain.
> 
> 
> Oh, and as a totally seperate personal gripe of mine (but also an example
> as of how to *not* do things): I would like the gnome-terminal dependency
> on libglade to be gone again. We had a perfectly working gnome-terminal
> without libglade several years ago. Then, for exactly no good reason, a
> libglade dependency was introduced. The reason it was introduced was pro-
> bably for (GUI) maintainability, which is totally void, as the GUI of
> gnome-terminal changed exactly zilch (or very little, which would have
> been easily made to the non-glade version), and as a result we have an
> extra dependency, and increased loading time.
> This is the exact opposite of what I would like to see happen (and have
> touched upon shortly above: reducing dependencies, and prototyping in a
> high-level language, following a reimplementation in a lower-level lan-
> guage): we had a perfectly working code base, and the GUI part had been
> static for years, still *is* static, and is most likely to be static for
> the rest of its life. There was exactly nothing (or extremely little) to
> be gained from this change.
> 
> kr,
> 
> Chipzz AKA
> Jan Van Buggenhout