[Twisted-Python] Wrapping a Perspective

[Rasjid Wilcox]

On 9/7/07, Phil Mayers <p.mayers at imperial.ac.uk> wrote:
> So, let me be be sure I've understood what you want:
>
> windows client
>  |
>  \- VB process
>     |
>   <COM>
>     |
>     \- python COM component
>             |
>   <maybe Twisted in a thread>
>             |
>   <some kind of complex object/callback capable RMI>
>             |
>      /- Python object ----> another COM object
>      |
>  /- Twisted Process
>  |
> windows server

That is pretty much it exactly!  :-)

> I have a hard time seeing why you wouldn't just use DCOM for this, but
> anyway...

Primarily because DCOM seems pretty fixed client -> server, whereas I
want to be able to send out a UDP multicast packet, discover which PCs
I wish to talk to, query a number of them, and then run some remote
methods.  And as indicated in your diagram above, the remote python
object may or may not be a COM object. The above arrangement also
allows the remote object to be running on a Linux box for example,
which is trickier (or at least more expensive) with DCOM.  I would
also consider running PB over SSL across the public internet, whereas
DCOM would have to be via a VPN.

The very long term goal is the gradual migration from VB to Python.
That is, gradually more all core code into Python, wraping Python code
up as COM objects so it can be used within the current program.  At
some point (might take a year or two) the VB program is nothing but a
front-end to Python code, at which point we could migrate the
front-end to wxPython or similar.  And at that point a migration from
Windows to Linux at least becomes a feasible option to contemplate.
Thus I have a long term motivation to avoid DCOM even if it was easier
in the first instance.

> Is the python COM component on the client in-process or out of process?

I have not decided that yet.  I have a feeling that out-of-process is
probably better in this case, but I'm still doing a fair bit of
research and learning on all this.

> I assume you have no issues creating and talking to the COM object on
> the server?

At the moment the 'server side' object in question is a Python object
that wraps up several COM objects and presents a much simpler
interface.

> Christopher Armstrong has already suggested looking at COM to see if it
> can support "async" components; it's been a while, but I seem to recall
> it can.

I believe it can, but the examples in win32com are a bit terse.

> You'll still need to run the reactor in a thread of course.

Yes!  And this is the part where I want some advice.  What are the
do's and don't of doing this?  And what are the most important things
I need to read / research?

Cheers,

Rasjid.