Re: GNOME, .Net and Mono

[Miguel de Icaza <miguel ximian com>]

> Well, if when writing a program in C, I'm forced to generate a Mono
> call, which generates byte code that then must be interpreted, resulting
> in an RPC, just to manipulate a window... ya, that'll suck.  *but*, if I
> can trim out all that CORBA and Bonobo and such to use one single small
> layer for RPC, I think it would be a lot faster.

A large part of what makes the .NET framework interesting, is that by
integrating multiple languages, things that are not well suited for
CORBA (like local components, or shared library components) are now just
an x86 call away.

With Bonobo, one of the rules is `Define chunky/coarse interfaces',
because there is a round-trip involved (context switching, bunch of
syscalls, etc).  With the CIL, a call to a separate component is
translated into a native call instruction.  Accessing public fields on a
class is translated into a two mov instructions on x86 machines.

So this is always nice to have.  Now, for talking to remote systems or
out-of-proc components, you still have to design chunky interfaces.

> As a wrapper, each language would only need *one* interface - the Mono
> interface.  So instead of needing PyGTK, PyGNOME, PyBonobo, PyCORBA, and
> whatever other ten billion, all slighty differently stylized Python
> wrappers, there'd just be PyMono, and everything would be accessible
> thru that.
> 
> For a scripting interface... well, Mono *would* be the scripting
> interface.  You've got your itnerpreter built in, you have a huge amount
> of support libraries, plus any exposed app functionality, and you won't
> be limited to language.  You won't need a Python itnerface, a Perl
> interface, a Ruby interface, a C# interface, etc. for each application.

Exactly!

Miguel