Re: getting started

[John R Sheets <dusk smsi-roman com>]

Phil Dawes wrote:
> 
> Martin Pool wrote:
> >
> > 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.

[snip]
 
> 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.

This is pretty true, in my experience too.  It seems most of the
books written about COM/OLE are a little starry-eyed.  It's
almost as if the authors start off with the assumption that
Micorsoft Is It, and limit their discussions to that narrow
scope.  No outside context.  Nothing outside of the Windows
platform has any bearing on their presentation.  Which is a
shame, because Windows does have some decent CORBA support, and
it _should_ be in the regular scope of discussion.

> > 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.

Unfortunately, no HTML versions.  OMG does have a number of
tutorials (don't know how good those are) at 

 http://www.omg.org/news/begin.htm

Also, there's a nice side-by-side comparison between (D)COM &
CORBA if anyone's interested in comparing the two approaches; it
gives a line-by-line comparison of the same program in both
models.  Lotsa pretty pictures, too.  (c:

 http://www.bell-labs.com/~emerald/dcom_corba/Paper.html

> > That's my two cents, anyhow.  I too would love to hear the architects'
> > vision for CORBA in GNOME.
> 
> 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.

This is a very fundamental point, and I would very much like to
see it too.  MS's Office suites always seem to carry so much
cumbersome weight around with them.  There's a lot of duplication
of tools, too.  They (office apps) sort of share functionality,
but it doesn't seem like they're sharing code as well.  Not as
much as they could be sharing, anyway.

But yes, it would be a tremendous jump to be able to switch tools
from within the same app.  Theoretically speaking, let's say I
use the Gimp tool palette 90% of the time when editing inline
images in my word processor; however, sometimes I just need that
extra special airbrush filter that MrWonderfulPaint (or whatever)
has.  So, I click on the Tools menu, switch image tools, and
boink! my tool palette has changed from Gimp's to
MrWonderfulPaint's.  My word processor doesn't care which tool
set I use.  Purty nifty.  Can't wait.

> 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.

Great stuff!  This'll be the building block upon which the
pluggable tools thing (mentioned above) comes into existance. 
The more CORBA language bindings we have, the more tools will be
ported/exported to work with GNOME in this fashion.  This'll
encourage more specialized use of languages, and will highlight
the benefits/strengths of each language.  "Stand back, this is a
job for Perl Man!"...or "This plug-in would be so much easier to
write in Objective-C...."  Good CORBA bindings will give
developers the power to shrug, roll up their sleeves, and just do
it.  Fewer compromises.  You'll no longer have to pick the best
language for the entire app...you'll be able to pick the best
language for the specific task.  The multi-lingual coder will
suddenly have twice the power, twice the flexibility.
 
> Anyway, enough babbling - I get a bit carried away talking about this
> stuff.

Oh, not at all.  (c:  I get excited about it too.

John