Re: GNOME & KOM/OP

[Phil Dawes <philipd parallax co uk>]

This debate is madness!!

It seems to me that nobody here really knows much about what they're
talking about - the arguments go:
	- We are going to be writing OLE/COM - it's really good.
	- We should be using KOM/openparts - it's already written and there's
interoperatbility issues to deal with
	- Well KOM is not well designed.
	- Why?
	- Have you read a book on OLE?
	- Have *you* looked at KOM?
	....etc....

It strikes me that components and compound-document architectures are
very new territory and not many of us have used them to the point that
we can be subjective about their designs. However, it is difficult to be
subjective when every book you read about a new architecture raves about
it without indication of its flaws.

On the one hand we have OLE/COM, which not many people know about, and
which AFAIK nobody here has programmed with. 
Miguel has read a book, and is an intellegent person, however I'm
worried that he hasn't read a subjective account of it yet (and nor have
I). The books I have read on COM have had nothing bad to say about it,
but then they haven't been comparing it with other established systems.
There *are* flaws in COM, however there are also workarounds and these
are taught as if there is no better way (e.g. monikers to identify
objects with state, using the registry to register components, reference
counting being un-balanced). I think it is important that we identify
the similar problem areas in OLE.

On the other hand we have KOM/OpenParts. This has already been
implemented, however AFAIK none of us in the gnome group have used it
yet. I would love to read more about it but haven't found anything other
than the slides from the kde pages (which don't say much). Stephan,
could you please email the group with the URLs of any information you
have on KOM/Openparts. (cheers)


Before I commence with my own opinions, here's my background of
knowledge (I'm not showing off ;-), I just want to give an indication of
the origination of my opinions).


- I have a year's experience developing C++ COM (ATL), and VB COM
clients at work. I have no knowledge of OLE however.

- I have a working knowledge of CORBA through studying the specs (also
at work), and reading Douglas Schmidt and Steve Vinoski's opinions on
the design (which appear to me to be fairly unbiased - they poke holes
in it and highlight the flaws). I have only used MICO and OmniORB with
fairly noddy test programs, but I do understand how they work. I've
written a small amount of code for the orbit project and am currently
designing an MT architecture for it based on patterns used in TAO
(haven't told anybody about this yet though - more details to come).

- I also have a fairly shallow knowledge of opendoc from reading 2 books
on the subject (when I used to be really enthusiastic about it), but
have never used it and am not aware of 'difficulty of development'
issues other than from off-the-cuff opinions from friends.




I'd like to venture the following opinions:

1) We don't need COM. CORBA replaces COM. There is NOTHING you can do in
com that you can't do with corba. (I have yet to be proven wrong on
this. Please feel free flame :-). 

This does not mean Corba is better than COM - they tackle a similar
problem from different angles. Note however that dcom does have
scalability problems (UDP pings), and doesn't provide a mechanism for
'discovering' new objects at runtime. I'd expect these will be fixed (or
patched over) in time.

This does mean that if we use CORBA, we shouldn't be trying to bend it
into COM. Corba has a different paradigm to COM involving objects which
'exist' without explicit creation or destruction, which makes it
difficult to immediately see how things work if you've come from a COM
standpoint. If you want to know how a particular feature of COM is
handled in CORBA, please email the gnome-components or orbit mailing
lists (as Miguel has done in the past). I think you'll (eventually) be
pleasantly surprised.


2) Windows has a lot of big programs which share data and facilities
using OLE e.g. office, developer-studio, exchange/outlook etc. What it
does not have is lots of small components which can be put together to
make big programs. IMHO it is the second that we should be persuing,
since the sort of coordination needed for big integrated programs like
office is huge (and I don't think we can compete with MS on that count).

To leverage this, Linux developers need to be able to develop components
which are loosely coupled with some common facilities but don't require
knowledge of their surroundings. OpenDoc promised the second half of
this, but I've never tested its claims. One point to note is that it did
require the use of class inheritance as a means of creating a component. 
Class inheritence is now considered bad news by the OO community since
it tightly couples the parent to the child. Signal/Slot style event
demultiplexing is the way to go IMHO as it decouples the server from the
client. (I'd have hated trying to port an opendoc component to another
system!)


3) I think we should develop this software through staggered release of
prototypes. It is likely that we'll get it wrong on first go and so it's
a good idea to try and restrict the impact of change as much as
possible. 

Of course we have to weigh the forces of 1) needing something now, with
2) needing the best. I hope that if everybody has the mentality 'we're
doing the best we can but we might be wrong so this might change' rather
than 'we're making a new standard which will be better than anything
else'.

BTW Sorry if I've offended anybody with my comments - that wasn't my
intention.

Cheers,

Phil.

P.S. It's worth having a look at some 'design patterns' books if you're
into designing this stuff - it's easy to think that one design is the
best  only to find that it has unforseen problems. Design patterns books
give you the information up front. Many people thought class inheritence
was a good idea and really overused it just a few years ago!

-- 
_______________________________________________________________________
 Phil Dawes                               |   My opinions are my own
 WWW:    err.. temporarily non-existant   |   and nothing to do with
 Email:  philipd@parallax.co.uk           |      my employer.