Re: getting started

[Phil Dawes <philipd parallax co uk>]

Martin Pool wrote:
> 
> On Tue, Aug 25, 1998 at 07:37:22PM -0500, Havoc Pennington wrote:
> 
> > About Monday I am hoping to start CORBA-izing Guppi (or at least
> > attempting to do so). Problem is I have minimal clue what that might
> > involve. :-) Tomorrow morning I am going to the bookstore to look for
> > relevant books.
> 
> I bought a copy of "Corba Distributed Objects Using Orbix" by Se\'an
> Baker (Addison Wesley), ISBN 0-201-92475-7I found it a nice tutorial
> for an experienced programmer who didn't know much about Orbix.
> 
> Mico comes with some examples, but they're pretty simple.
> 
> In fact, I've found the biggest problem in trying to learn about this
> stuff is: "OK, I know how to write Hello World.  What's a useful
> design pattern for a desktop app?"
> 
> I've been wondering if it would be worth reading a bit about
> OLE/ActiveX for inspiration.

My advice is borrow a book, don't buy one. If you're looking for a
simple overview of COM/OLE/ActiveX you could do a lot worse than
'Understanding ActiveX and OLE' by David Chappell - Microsoft press.
It's an interesting read and provides margin notes to make it quicker to
skim chapters you aren't interested in.

Note however that none of the books I've read (bar 'distributed objects'
by ofalli & cp) actually attempts a critical analysis of COM/OLE.
Generally you get 'this is how it is', and sometimes you even get 'this
is how it is and it's really good' without much explaination of why or
any comparison with other object systems.

 
> All of the specifications are available for download from www.omg.org
> if you dig deep enough.  They're pretty readable, but they're
> definitely specifications, not tutorials.
> 
> > A concrete question: is CORBA something well-standardized like C, such
> > that any book will do, or does it have significant ORB-specific aspects?
> 
> My (very non-expert) assessment is that CORBA is roughly as
> well-standardized as C, or perhaps slightly less well: there is a
> specification and standards body, but they leave quite a few details
> of syntax and semanticsup to the implementor.  When moving between
> different OSs in C you might have to allow for endianness, word size,
> and different libraries.  When moving between ORBs you might have to
> allow for slightly different interpretations of the spec or function
> names.   All IIOP implementations ought to be compatible.
> 
> I hear from friends who work with CORBA a lot that current commercial
> implementations work well but do have problems: organizations that are
> serious about it try very hard to get source licenses.  So, it seems
> to me like there's a lot of room for the many-eyes debugging advantage
> of a GPL'd ORB.
> 
> > Does anyone have suggestions on what to do/read? Specs? What books did you
> > learn from? Source code?
> 
> That's my two cents, anyhow.  I too would love to hear the architects'
> vision for CORBA in GNOME.
> 


First, I want to see gnome do with corba what MS have done with COM
components. Specifically I want components to be a replacement for
shared libraries under gnome, to allow them to be written in any
language and used from any other.
COM succeeds in this area very well, providing virtual-call fast access
to component operations from compiled languages and dynamic access from
scripting languages.

I also want to see an open-doc ish approach to compound documents, where
the thrust of the exercise is to provide the user with a load of small
tools which they can use to author their own document rather than a
large suite of office applications which work together. MS have got this
wrong IMHO - Can I use corel-draw's tools to draw diagrams in
powerpoint? I don't think so.

I don't however want to see us go down the opendoc and OLE route of
having a framework of large interfaces which all components must
implement.  Historically microsoft have done a lot of this, fudging the
issue by providing wizards that generate the boilerplate code
implicitly. With the advent of the internet microsoft are now starting
to back-track away from this approach in order to reduce the download
times of active-X objects. Now, any COM component can be an active-X
object - the container QueryInterfaces for the functionality that it
requires.

Baboon architects must be very careful to check COM/OLE ideas before
copying them. Connection-points and outgoing interfaces seem like a very
good idea on first read, but in practice they force clients to implement
operations in interfaces that they might not need - gtk's signal/slot
mechanism is IMHO a much better event model for event driven dynamics in
applications.

Finally I'd like to make multi-language projects possible. It would be
nice to have ORBit finish the C/C++ battle by having all C++ objects
visible from C as if they were C objects, and vice versa. For this to be
possible it has to be very easy to write corba components in both
languages, and efficiency overhead has to be minimal (i.e. virtual-call
fast). Scripting languages must also be able to author and use
components with ease - it ought to be possible to export objects from
perl and python without any intervention from the programmer past
initialising the orb. 

This would provide scope for rapid prototyping of applications with
scripting languages, and then allow replacement of scripted code with
compiled code on a component by component / object by object basis.
Couple this with gui building tools and we'll finally have a real RAD
environment with which to deploy our applications.


Anyway, enough babbling - I get a bit carried away talking about this
stuff.

Cheers,

Phil.

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