Embedded COM using Python + Remote OLE Automation?

[Warren Postma]

Between two windows machines, COM and DCOM is ubiquitous. On non-MS
platforms, as well as on embedded systems, the traditional approach involves
a gateway [example: CORBA to COM gateway]. What about a third alternative?
It may be possible, without benefit of the source code to COM and DCOM, to
construct a service for any non-windows Python-supported-platform to let it
talk to any Automation interface on any Windows platform, or indeed, to
provide it's own automation interfaces, callable from Microsoft. Get me
here? I'm talking about doing at least the slower and more "script oriented"
IDispatch level of COM over a network, from the ground up. Now that sounds
hard, doesn't it?

First, the ground rules I can think of:

- Implementing my own RPC and/or DCOM is out.
- I have a ws2_32.dll emulation layer that is winsock-compatible
- I have a subset of the core Win32 API to work with.
- I'd rather not do a "gateway" if I can avoid it.

Why Not Do a Gateway:

That would work like this:

Write a Python Service that is the "Python Remote COM Server", running on my
NT machines that receives requests to instantiate an IDispatch interface on
it's own machine. I would then require all NT servers to be running this
service, so I can remotely talk to IDispatch interfaces on it.  I then have
to do my own security and authentication, but it would generally work.



Behind Door Number 3, Another Possible Alternative:

Somehow emulate the TCP-IP socket-level for the special case of IDispatch
invocations , and without RPC or DCOM.

Microsoft's old and simpler way of doing automation over a network was
called Remote OLE Automation.

If this is still supported by Windows NT and 2000, is it documented
anywhere? Has anyone ever used it with Python? It is old and perhaps even
deprecated by Microsoft now, but it might be a great way for me to network
embedded Python objects to other Windows machines, and so on.

The benefit to the Python community would be two fold:

1. Embedded systems could talk COM [at a limited scale, over a slow
interface]
2. Non-Windows systems like Linux could take a crack at COM services on
Windows.


Or, am I totally wrongheaded about this, and I should be looking at XML-RPC
and SOAP? ;-)

Warren