I've only been playing with Twisted seriously for a couple of weeks, but as far as I understand inline callbacks, they just make the code 'look' synchronous, but the end result is still a deferred. In my playing with them, they make twisted code much more succinct and generally easier to read, but it is all still really just deferreds underneath and there is no actual blocking going on.

Correct. Effectively, it uses python generators to make the code "nice"; state variables can be kept as function-locals, and flow control can be somewhat easier to visualise.

I want to have my python code being called from an external process via COM, and the external process will expect to be calling a class method that will do something (blocking as long as required) and then return the result. Rewriting the external app to deal with everything being async is not an option.

I suggest you abandon Perspective Broker; it's a fully async protocol, and by trying to call it in a sync/blocking manner you're going to get nowhere fast. Use something easy like XMLRPC. Twisted can implement that as a server with full deferred-capable semantics, it'll run over HTTPS, it's got authentication, it's got .net bindings etc.

That doesn't make any sense: XMLRPC can be used asynchronously, as PB can. Switching to XMLRPC won't change anything about his situation, the biggest problem being that his COM interface doesn't support callbacks (?).

I read the OPs problem is precisely the opposite; they are wanting to use PB sync (which involves horrible reactor tricks).

On 9/6/07, Phil Mayers wrote:

I suggest you abandon Perspective Broker; it's a fully async protocol, and by trying to call it in a sync/blocking manner you're going to get nowhere fast.

Use something easy like XMLRPC. Twisted can implement that as a server with full deferred-capable semantics, it'll run over HTTPS, it's got authentication, it's got .net bindings etc.

I have used XMLRPC in the past (until recently it was my main use of Twisted), but it does not support complex objects, nor callbacks. PB does both, but just in an async manner. I could use CORBA instead of PB, but then I'm likely to be in the position where I want to learn Twisted and CORBA - I'd rather just learn Twisted, as long as I can get it to play with Windows COM in the way that I want.

On 9/7/07, Phil Mayers 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> | | /- 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.