Re: Plans for 2.8 - GNOME Managed Language Services?

[Ryan McDougall <ryan mcdougall telusplanet net>]

On Fri, 2004-03-26 at 10:55 -0500, Havoc Pennington wrote:
> On Fri, 2004-03-26 at 00:05, Ryan McDougall wrote:
> > 
> > With the refusal of Sun to open up Java, that pretty much excludes it
> > from consideration as the base of implementing VM+obj system.
> 
> Slow down - they haven't open sourced their implementation. We have
> piles of free Java VMs, though.

Unlike other options (mono/parrot/etc.) Java was never designed to run
any language other than Java. Although there is no technical reason why
we cannot shoehorn the JVM into a platform role, such that someone can
say run C# on it, without any support from Sun to take the project to
the community, I think it would be very tough. More importantly I fail
to *why* we should support Sun's Java if they have no confidence to
release control to share us.

> 
> >  That
> > leaves only three options:
> > 
> > 1. Make our own solution - perfect except for the *huge* amount of work
> > this option represents.
> 
> i.e. basically impossible.

Only impossible if there is no will, which I assume there isn't.

> 
> > 
> > 2. Parrot VM+Object system - possibly not fast enough for statically
> > type languages
> 
> Unfinished and kind of a research project.

It will be the VM for Perl and Python, so I fail to see why it would
remain unfinished.

> 
> > 
> > 3. mono CLR+CLI - everything we want, but invented by microsoft

Just to be absolutely clear: I DON'T want .NET or C#! I'm proposing we
use the ECMA __standard__ Common Language Runtime (CLR aka VM) and ECMA
__standard__ Common Language Interface (CLI composed of Common Type
System and Common Language Specification, aka Object System).

> 
> Microsoft hasn't opened this yet either - and even if they had, you're
> likely to get a fork if you try to put it in GNOME.

Since mono has a working free software implementation of the two above
items, there is no need for MS to open source them. They are in fact
public standards which we are free to use. TCP/IP is a standard that is
probably covered by some patent somewhere, CORBA is a standard probably
covered by some patent somewhere, etc. But because they are all
standards, they must be licensed under reasonable and non-discriminatory
terms; otherwise NO ONE would use them. How on earth could MS torpedo us
if we implement a standard?? To repeat, there will be no .NET in GNOME,
there need not be any C# in GNOME, but there is *nothing* stopping use
from implementing _public_ _standards_ as a base to build our own .NET
rival.

As to the forking issue, you seem to know why there will be a fork if
ECMA standards are used in GNOME, so could you please let us know who
exactly will be doing the forking, and what their reasons are? Provided
the community was educated on the fact that GNOME is implementing a
*standard* that just happens to be a subset of .NET, I fail to see why
there would be grounds for a fork.

Is this about not pissing off Sun? ECMA CLR+CLI doesn't stop people from
using Java on top of free software. In fact there whole reason why I
propose we use CLR+CLI *only* is so we mandate a common platform, *not*
to mandate a single language. Java would run just as well as C#, since
it is nothing more than a common runtime and object system.

Are you implying that Sun will take its toys home if we don't use Java?
I would really like to understand your position more clearly, because I
really can't see what the problem is with ECMA standards.

> 
> I would also argue that ECMA core _isn't_ everything we want - it lacks
> a class library set, it doesn't tie in well with the server-side, we

Gtk# is a starting point. So is CLASSPATH. ECMA core would allow either
C# or Java (via IKVM) to work out of the box, all free software. We
could do more, or stay with what C# or Java supplies. Once the _common_
_platform_ is there, the community can take it where it pleases.

> don't have the "ecosystem" of third party tools, IDEs, libraries,
> documentation, training, marketing, and support that you get with the
> Java or .NET platforms.

No, you would get exactly both of the "ecosystems", since both would run
equally well once they (the pro-language camps: Sun, Novell, etc.)
supply their own compiler. Thats *why* I think its doable, thats why we
choose a subset of .NET, not *all* of .NET or *all* of Java.

> (Note that with '.NET platform' I include things outside the ECMA core,
> because you need the full platform not just language to get this
> "ecosystem")

Sure, if we blanket copy .NET, we can piggyback to a greater degree on
MS, but that also makes MS a bigger threat to us. Thats why I say we
only use the ECMA subset, which is relatively safe, and build our own
"ecosystem" from there. For example only: we could expand Gtk# to
include or wrap all our current C libraries, and have our own .NET
rival-able stack.

> 
> There are no good options, I grant you. But these three have showstopper
> issues at present.

I would very much like to know how mono is a show stopper. Sure the
patent thing is a threat, but it always is. At least with EMCA, we have
*some* assurances, unlike Sun which may one day pull a SCO.

> 
> My suggestion if we want to do something in 2.8 and we can't get people
> behind "open source Java subset" is:
>  - make full introspection data on the GTK+ API more formally part of 
>    GTK+, so language bindings aren't maintaining this themselves
>  - allow parts of GNOME in PyGTK+
> 
> Gets us some of the development efficiency advantages. It's not really a
> long-term answer to the larger concerns, but it's useful for now.
> 
> Havoc

Thanks for all your comments, Havoc. I think its important for the
community to have this discussion. I would however, very much like to
hear your take on what Sun and Novell guys are saying behind closed
doors (as it were), and bring them out to take some sort of stand on
this issue one way or the other. Specifically, who is going to fork and
why?

Cheers,
Ryan