PythonCom equivalent on Linux!
aleaxit at yahoo.com
Sun Oct 17 17:13:31 CEST 2004
John <johng2001 at rediffmail.com> wrote:
> across clients. I think you are pointing to something akin to IPC like
> DDE. If you think CORBA can be used like an ActiveX in-process
> control, please let me know how.
CORBA itself allows every activation model one typically wants:
in-process, external-process, remote-host. Just choose a CORBA
implementation ("broker") that provides a support you like for your
preferred activation models. PyORBit, for example (which you can find
at <http://ftp.gnome.org/pub/GNOME/sources/pyorbit/2.0/>), working
together with the ORBit2 object broker, should be fully capable of both
using and being used by in-process servers and clients, as normally
required for the application it's optimized for (Gnome). Other object
brokers might also be suitable for your needs.
Different Corba object brokers can interoperate, but might not be able
to fully utilize each other's components with in-process activation
(communication at the in-process level may be more efficient, but is
typically more intrusive and less standardized, than clean communication
via the standardized Corba inter-brokers protocol, IIOP). If your main
thrust is building the equivalent of ActiveX "controls" (components with
a visual interface), and GTK/Gnome is acceptable to you, PyORBit and
ORBit2 might suit you best, for example.
I have used COM extensively in the past, and Corba more modestly. It
appears to me on the basis of this experience that Corba is technically
superior to COM. Undoubtedly, on Windows, COM has the advantage of
being widespread; particularly for the purpose of automating
("scripting") applications, being able to rely on just about every
application of note being forced by market demand to provide _some_
level of COM "scripting" interface is quite enabling (even though many
of those interfaces are badly designed, sprawling, ungainly hulks --
mostly not due to COM problems, but to defects inherent in the
architecture and internal design of the applications in question --
nevertheless being able to get at them SOMEhow is still better than not
getting any access to them).
Neither Corba nor any other standard (XPCOM, UNO, etc, etc) is likely to
gain total ascendancy comparable to what COM gained in Windows, in my
opinion. The very existence of many good standards competing in good
part for the same set of niches, and each enjoying significant support,
precludes that ascendancy. Moreover, there are objections to the whole
concept in some sectors of the Unix community; Eric Raymond's excellent
book, "The Art of Unix Programming", has a short section which
summarizes those objections, albeit a bit tersely (IMHO, the book is
well worth reading even if you think you'll never program for anything
but Windows, BTW: it has many important lessons to teach).
More information about the Python-list