Re: GNOME & KOM/OP

[David Jeske <jeske home chat net>]

On Fri, Aug 07, 1998 at 11:36:29PM +0200, Dirk-Jan C. Binnema wrote:
> 
> -----Original Message-----
> From: David Jeske <jeske@home.chat.net>
> To: gnome-list@gnome.org <gnome-list@gnome.org>
> Date: vrijdag 7 augustus 1998 21:09
> Subject: Re: GNOME & KOM/OP
> 
> >The philosophy of COM (IMO) is quite good, and as you say, the
> >implementation on windows is quite bad. They recognized some key
> >traits which make COM able to gracefully handle compatibility and
> >backward compatibility.
> 
> Somehow, suddenly, MS-stuff has become _cool_ among Linuxians/Gnomes ;-)
> This is a good thing, we should take *good* ideas from whomever came
> up with them.

I can't speak for everyone. However, for myself personally, I would
never consider myself a "linuxian", or a "microsoftian". I appreciate
good software. I go where the good software is. I've been frustrated
with the Linux camp as a whole for quite some time because the "if you
want it on your machine compiler it youself" mentality only works for
people willing to spend time working on and administering their
machine. I used to be a UNIX person at heart, until I decided I no
longer wanted to spend more time administering my machine than using
it. I'm still primarily a unix user, but the way I set things up and
the tools I write are very non-unix in philosophy.

So I suspect the rise of ideas coming in from worlds outside linux
(i.e. MS, NeXT, Mac, etc) are more because Gnome/KDE represent a
statement to developers that the Linux community that an attempt is
being made to find a way to make things on Linux nice to use. 

My real interest in Gnome/KDE is in getting Linux to adopt a software
encapsulation system which allows user transparently and safetly
install and uninstall things. RPM is a baby step, but nothing
more. Users should be able to install apps and components easily and
in a managed form. One where they don't have to be administrator. One
where they can install multiple versions of the same apps. Where apps
can register themselves to handle services without editing some
app-specific text config file. One where installing an app makes it
available in an app launcher without editing window manager specific
configuration files.

> I don't think we can be really specific about GOLE2 before some
> people put their thoughts in specs. However, I'd like to make one
> more point about the differences between OLE2 and Corba.
> 
> One of the good things about COM/DCOM is the fact you can quite
> easily turn your local COM component into a distributed DCOM component.
> I think this is important stuff. You wouldn't want to rewrite your
> GNOLE2 components into Corba/IIOP, just to be able to use the in a
> distributed
> fashion. There shouldn't be to much of a difference between local and remote
> components, just like XWindows...

My understanding is that all corba components are network-aware. With
a standard corba system, it takes more work to access corba objects in
your address space. There is a project called "ILU" (Inter-Language
Unification) which exports objects to the network via a Corba/IIOP
compliant prototcol, but also allows fast in address-space and
fast-in-machine (via shm) communication.

> So, while using ideas from OLE can be good, IMHO the APIs/object models
> for remote and local components (objects) should be very similar.

Agreed. Unfortunatly, techniques which deal with C/C++ objects usually
rely on generating stub code to do network support, and this isn't a
very good solution. There just isn't a way to marshal paramaters in
and out of a C-calling-convention function in a platform independent
way. For example, Objective-C's DO (distributed objects) makes it
possible to treat local and remote objects the same, and it works
transparently on any object with no stub code. This is possible
because the Objtive-C runtime has all the type information about
objects and methods, and it can marshal and unmarshal paramaters to
and from method calls.

> Remember that this is one of the very rare occasions one can
> actually define a component model for a (potentially) very large
> audience. Lets make sure we make the right decisions.

I like the mentality which has pervaded so far. Namely, the
structuring of Gnome code such that it's an 'object-model-agnostic'
body of code. (or am I thinking of just the gtk+ orginization?)

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske@chat.net