On 8/6/02 1:26 PM, "Hal E. Fulton" <hal9000 / hypermetrics.com> wrote:

> ----- Original Message -----
> From: "Christopher Browne" <cbbrowne / acm.org>
> Newsgroups: comp.lang.ruby
> To: "ruby-talk ML" <ruby-talk / ruby-lang.org>
> Sent: Tuesday, August 06, 2002 3:02 PM
> Subject: Re: COM on Unix?
> 
> 
> (snip large informative section with 5 URLs)

The entireX package seems to be free and fairly complete.
> 
>> Of course, it's pointless to _have_ COM on Unix systems if there are
>> no applications that may be meaningfully automated using COM, and
>> you'll find that that is in fact the case.
>> 
>> COM is only useful for "automation" if applications deploy COM
>> interfaces, and on Unix, nobody deploys COM interfaces for this
>> purpose.
>> 
>> The most analagous thing would be CORBA, and there are only a limited
>> population of applications associated with the GNOME "desktop
>> environment" that offer CORBA interfaces for pretty _limited_
>> automation of some capabilities.
> 
> Thanks for this post. It's a good reality check.

I just want to second that.

> However: Hypothetically speaking, isn't it
> imaginable that something like COM on UNIX
> might be useful if it existed?


Unix is fine without it where Unix is. It's just that Unix can't go certain
places, like the desktop in the enterprise. ;)


> I've had a fleeting thought of making a little
> package that would allow embedding a Ruby interpreter
> and running dRb or something... if it were easy enough,
> people might use it to enable their apps.
> 
> And any app for which we had source could have it
> grafted on. Daemons especially might benefit from
> such an interface, I'm thinking. Agree/disagree?
> 
> I'm not up to the task, though, so I'm just dreaming.

I still like just using XML. With COM, the programmer of the automatable app
has to specify that app's object model in IDL, then the OS somehow registers
the service that the app provides and would be clients have to use system
calls to query the registry. I don't see the point. An XML file can provide
the same information about the object model.

We started this discussion with most everybody saying that a good design
pattern envisioned the GUI communicating with the main program only through
messages both for portability and SOC reasons. So you already have guts of
the program acting as a server to the GUI client. Ruby, or any other
language for that matter, can just be an additional client. The program
doesn't need to know that messages are coming from a scrip rather than the
GUI.

The details of how messages get passed are operating system specific. The
Ruby programmer can remain blissfully ignorant of them.

Microsoft has already shown that this mechanism can work by putting a
version of VBA on it for the Mac.

BTW, I'm an equal opportunity naysayer. I think CORBA is at least as much
overkill as COM.

-- 
Many individuals have, like uncut diamonds, shining qualities beneath a
rough exterior. - Juvenal, poet (c. 60-140)