Re: Focusing on innovation re: mono, python et al

> That's exactly what I meant. Windows starting to be shipped (well,
> starting...) with everything but the kitchen sink, and I hate that too.
> I don't even *have* a camera, why would I need a video editor???
> The question that I'm asking, and which we should be asking ourselves
> is, does gnome really need to endorse everything and the kitchen sink in
> order to become successfull? I think not. We do need applications to
> survive, but that doesn't mean that we (or they) will be any less suc-
> cessfull if we don't include them, given the success they have now.

GNOME is useless if there are no applications running on it. That's the
key success factor. Applications.

It's not so important which applications do gnome include, since distros
can take this decision, depending on the specific target of the distro.
What's important for gnome is to provide a good infrastructure for
developing and running applications.

Some of the posts in this thread have been defending the "purity" of
GNOME, and they have been against the inclusion of Mono because it could
lead to a bloated and memory hungry GNOME. But "purity" is an abstract
concept, we should look at the reality. The reality shows that people
are using everyday Mono based applications, and they are happy with
them. The reality shows that new applications are being built with high
level languages and frameworks like Mono and Python, not in C.

If there are memory and performance problems with Mono or Python,
excluding them from GNOME is not a solution, because like it or not
users will still use them to run applications. 

GNOME should adapt to this reality if it wants to survive. And adapting
here means giving the best support it can provide to high level
languages, like it did in the past for C.

The Mono framework overlaps in some areas the existing gnome framework,
yes, but this problem is not specific to Mono. That's a problem you will
have with any other high level language/framework, because the gnome
framework is based on a C API, and some of this API do not fit well in
higher level languages. Or maybe it could fit, but at the cost of losing
ease of use and a better integration with the rest of the framework.

If the goal of a high level language/framework is to make it easier to
develop applications, it can't be constrained by the underlying C api.
If it means duplicating libraries and having for example two xml parsers
in memory, so be it. It's still a good deal.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]