PythonCom equivalent on Linux!

[John]

Is there an equivalent of COM on Linux that I can get through Python.
My need is to have some sort of language independent component
framework. I can think of CORBA but I have to have a server running. I
prefer not to. I just need Python components for local consumption in
other languages. I remember Gnome libs having some thing like this.
Any thoughts?

 

[Ville Vainio]

john> Is there an equivalent of COM on Linux that I can get
john> through Python.

Mono appears to be the future of COM equivalent technologies on
Linux. Python support just isn't stable/mature there yet.

There is also xpcom.

john> My need is to have some sort of language independent
john> component framework. I can think of CORBA but I have to have
john> a server running. I

How critical is this criterion? I would definitely go with CORBA.

 

[Paul Boddie]

john> Is there an equivalent of COM on Linux that I can get
john> through Python.

Mono appears to be the future of COM equivalent technologies on
Linux. Python support just isn't stable/mature there yet.

It depends what everyone means by "COM equivalent". If you mean it as
some kind of distributed object technology, then there are a lot of
CORBA-related solutions out there: ORBit (PyORBit vs. ORBit-python),
Fnorb, omniORB (omniORBpy), and so on. In addition, you have a
selection of unstandardised technologies to choose from, too.

There is also xpcom.

As well as UNO (PyUNO), but that is arguably in the realm of the other
principal interpretation of "COM equivalent": the application
automation technology. On that front, there's ORBit and Bonobo for
GNOME-based applications (I believe) and DCOP for KDE-based
applications. Eventually, there'll be standardisation of such
technologies, and I imagine that D-BUS fits in somewhere here.

john> My need is to have some sort of language independent
john> component framework. I can think of CORBA but I have to have
john> a server running. I

How critical is this criterion? I would definitely go with CORBA.

Yes. Years ago I had a lot of fun with ILU, but I imagine that any of
the more mature/supported Python-compatible ORBs would be suitable.
Certainly, omniORB (http://omniorb.sourceforge.net/) would be my first
consideration.

Meanwhile, beware of suggestions that you use SOAP or XML-RPC! If
remote method calling is what interests you, such technologies are not
*directly* applicable (unless, in the case of SOAP, XML documents are
the primary representation of data in your system).

Paul

 

[Jarek Zgoda]

Is there an equivalent of COM on Linux that I can get through Python.
My need is to have some sort of language independent component
framework. I can think of CORBA but I have to have a server running. I
prefer not to. I just need Python components for local consumption in
other languages. I remember Gnome libs having some thing like this.
Any thoughts?

Don't you think that Windows with all its stuff is more "serverish" that
running separate CORBA server process? Anyways, who runs RPC server on
client machine...

 

[Jarek Zgoda]

john> Is there an equivalent of COM on Linux that I can get
john> through Python.

Mono appears to be the future of COM equivalent technologies on
Linux. Python support just isn't stable/mature there yet.

From my point of view, DCOP is perfect equivalent of COM. Mono (and
other dotnet implementations) may become some day.

 

[John]

It depends what everyone means by "COM equivalent". If you mean it as
some kind of distributed object technology, then there are a lot of
CORBA-related solutions out there: ORBit (PyORBit vs. ORBit-python),
Fnorb, omniORB (omniORBpy), and so on. In addition, you have a
selection of unstandardised technologies to choose from, too.


As well as UNO (PyUNO), but that is arguably in the realm of the other
principal interpretation of "COM equivalent": the application
automation technology. On that front, there's ORBit and Bonobo for
GNOME-based applications (I believe) and DCOP for KDE-based
applications. Eventually, there'll be standardisation of such
technologies, and I imagine that D-BUS fits in somewhere here.


Yes. Years ago I had a lot of fun with ILU, but I imagine that any of
the more mature/supported Python-compatible ORBs would be suitable.
Certainly, omniORB (http://omniorb.sourceforge.net/) would be my first
consideration.

Meanwhile, beware of suggestions that you use SOAP or XML-RPC! If
remote method calling is what interests you, such technologies are not
*directly* applicable (unless, in the case of SOAP, XML documents are
the primary representation of data in your system).

Thanks. I think DCOP and Bonobo are what I am looking for. I use
omniORB. I dropped SOAP for most part after I found that CORBA
complexity was just a myth. I just did not think CORBA was what I
needed for this particular project.

 

[Ville Vainio]

john> use omniORB. I dropped SOAP for most part after I found that
john> CORBA complexity was just a myth. I just did not think CORBA

Tell me about it! CORBA is perceived as complex because of the
low-levelish and painful C++ binding, but the Python binding proves
that it's actually a pretty simple way of doing the complex thing.

Duncan Grisby (of omniORB fame) debunks lots of CORBA myths in his
presentations that are available online:

http://www.grisby.org/presentations/

Mark my words, CORBA's day will come ;-).

 

[Duncan Grisby]

Is there an equivalent of COM on Linux that I can get through Python.
My need is to have some sort of language independent component
framework. I can think of CORBA but I have to have a server running. I
prefer not to. I just need Python components for local consumption in
other languages. I remember Gnome libs having some thing like this.
Any thoughts?

Other people have already mentioned that CORBA may be a good choice
for you, and pointed you to some of my presentations about the
issues.

One thing nobody has mentioned yet is your statement that for CORBA
you "have to have a server running". That is one of the common myths
about CORBA. For CORBA to work, there is no need for some kind of
separate server. Processes using CORBA talk to each other directly,
not through some other server.

Cheers,

Duncan.

 

[John]

One thing nobody has mentioned yet is your statement that for CORBA

you "have to have a server running". That is one of the common myths
about CORBA. For CORBA to work, there is no need for some kind of
separate server. Processes using CORBA talk to each other directly,
not through some other server.

Hi Duncan,
I found out about the pleasure of CORBA for the first time with your
omniORBPy. That said, I am thinking of my components not to be
seperate processes (OK! I won't call them servers ) running all
the time. Take an ActiveX control for example. It is an in-process
component, comes to life only when a client application creates it and
consumes zero memory otherwise. Deployment is simpler than deploying a
daemon. This was what I wanted. I did not need to preserve state
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.

Thanks.

 

[Alex Martelli]

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


Alex

 

[John]

CORBA itself allows every activation model one typically wants:

in-process, external-process, remote-host.

That I did not know. Thanks for the info. I will check PyOrbit. I
currently use omniORBPy and occationally Fnorb.

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.

My main interest is not GUI controls. Just being able to make code in
any language available to any other language on the same machine
regardless of the types of languages (static/dynamic, bytecode/native)
since all languages are good in something than others. Also, I am
frequently frustrated as my language choices seem to be based on
availablity of libraries and tools rather than languages due to the
nature of my projects. So I would like to be able to write part of the
code in Python, part of it in Pascal and maybe some in Java and have
all talk to each other easily through some sort of interface.
Something like a DLL/SO or COM. CORBA seems to be the best bet so far.

 

[Alex Martelli]

My main interest is not GUI controls. Just being able to make code in
any language available to any other language on the same machine
regardless of the types of languages (static/dynamic, bytecode/native)

Ah, yes, that was originally the holy grail of ILU, which, if I recall
correctly, did evolve basically into a CORBA solution eventually. At
any rate, Corba surely has the potential to help (better than COM does
on Windows, for this purpose), assuming you can find acceptable brokers
for your purposes (Corba specifies language bindings for a bazillion
languages, but any given broker may not offer _all_, I believe...).


Alex

 

[Eric Brunel]

Alex Martelli wrote:
[snip]

(Corba specifies language bindings for a bazillion
languages, but any given broker may not offer _all_, I believe...).

Just a precision to be sure no-one will be misunderstanding this: nothing
prevents you to use different CORBA ORBs for your different languages. Since all
ORBs use the same protocols and architecture, they interoperate quite gracefully.

I used once fnorb for Python (http://www.fnorb.org/) and JacORB for Java
(http://www.jacorb.org/) and everything worked OK.

But of course, you may get some functions implemented in some ORBs, but not in
other ones (e.g activation models...)

The OMG site has a good list of ORBs, free or commercial:
http://www.omg.org/technology/corba/corbadownloads.htm

HTH

 

[Alex Martelli]

Alex Martelli wrote:
[snip]

(Corba specifies language bindings for a bazillion
languages, but any given broker may not offer _all_, I believe...).

Just a precision to be sure no-one will be misunderstanding this: nothing
prevents you to use different CORBA ORBs for your different languages.
Since all ORBs use the same protocols and architecture, they interoperate
quite gracefully.

Absolutely, as long as typical inter-ORB mechanisms (IIOP first and
foremost, I believe that's the only standardized one, right?) are
acceptable for your purposes. The OP seemed to think that this couldn't
possibly be the case for _his_ purposes and I didn't challenge that
assumption.

I used once fnorb for Python (http://www.fnorb.org/) and JacORB for Java
(http://www.jacorb.org/) and everything worked OK.

But of course, you may get some functions implemented in some ORBs, but
not in other ones (e.g activation models...)

Right. A fully standard compliant ORB need not talk to other ORBs by
anything else except IIOP (if it does more, swell, but it don't hafta).

The OMG site has a good list of ORBs, free or commercial:
http://www.omg.org/technology/corba/corbadownloads.htm

Very good site to check for anything CORBA, btw, so tx for posting the
URL! I should have dome that myself but didn't think of it, sorry.


Alex

 

[John]

The OMG site has a good list of ORBs, free or commercial:

Very good site to check for anything CORBA, btw, so tx for posting the
URL! I should have dome that myself but didn't think of it, sorry.

I find this one very helpful for quick comparisions.
http://adams.patriot.net/~tvalesky/freecorba.html

Thanks all for the responders who took the time.

 

[Duncan Grisby]

[...]

Just a precision to be sure no-one will be misunderstanding this: nothing
prevents you to use different CORBA ORBs for your different languages.
Since all ORBs use the same protocols and architecture, they interoperate
quite gracefully.

Absolutely, as long as typical inter-ORB mechanisms (IIOP first and
foremost, I believe that's the only standardized one, right?) are
acceptable for your purposes. The OP seemed to think that this couldn't
possibly be the case for _his_ purposes and I didn't challenge that
assumption.

Going further, if you want CORBA communication between different
languages in a single process, you basically have to use the same ORB
for all of them. There is no CORBA standard for binary linking between
languages as there is in COM. In theory, in some circumstances you
could do it, but they would still end up talking IIOP through the TCP
loopback interface. In practice, C level symbols often clash between
ORBs, making it fundamentally impossible. You certainly can't have two
different C++ ORBs running in one process, for example.

CORBA is just not intended for that kind of in-process
interoperability. If you absolutely have to have that, you have to
stick with just one ORB. omniORB allows efficient communication
between C++ and Python in one process, and I assume ORBit does too.
Unfortunately, ORBit has historically not been too bothered about
sticking to the CORBA specs, but it might be better now.

[...]

Very good site to check for anything CORBA, btw, so tx for posting the
URL! I should have dome that myself but didn't think of it, sorry.

Good, but that page is hopelessly out of date. I don't think anyone at
the OMG maintains it. If they do, they're doing an awful job...

This page has some useful information about the ORBs out there and
what they support:

http://www.puder.org/corba/matrix/

Cheers,

Duncan.