DDE vs. COM for Python Windows apps

[Kevin Walzer]

I'm developing a Windows version of a Mac/Python app and I'd like to add
a scripting interface to it. On the Mac I do this via Apple Events--this
is an Apple technology that allows applications to drive other
applications and query them for data using a message-passing interface.
Each application defines a suite of commands and/or data objects that it
will invoke, depending on which Apple Event is passed to it; these
commands and data objects are most commonly documented in an AppleScript
API dictionary, though there are other ways to send Apple Events as well.

On Windows, I've found two separate mechanisms that seem to offer what
I'm looking for: Dynamic Data Exchange (DDE) and Component Object Model
(COM). As I understand it, DDE allows data transfer and
command-automation between applications via a lightweight
message-passing interface. COM seems to offer similar functionality,
with a much more complex learning curve.

The main complaint I've seen about DDE is that it is very old. The main
complaint I've seen about COM is that it is very complex and very
brittle. Based on my research, it seems that DDE might be sufficient for
my needs--I want other applications to be able to send commands to my
application and have data returned to them. But I'd like to have a
better understanding of the merits of each.

Can someone summarize the advantages that COM might have over DDE, in a
Pythonic context?

--Kevin

 

[Chris Angelico]

The main complaint I've seen about DDE is that it is very old.

I can't speak about COM, as I have not used it to any great extent,
but DDE has a number of things going for it. Firstly though, "old"
does not need to be a criticism. How many network administrators use
ping(1) on a daily basis? Yet that utility was written in the early
1980s - in computing terms, that's pretty old.

DDE is implemented as window messages. This means it works with
anything that has a window; it might not be easy to send DDE requests
from a console application, and it would be quite tricky to receive
them in a console. It also means that the system can hang until the
request is dealt with. However, it is extremely simple and easy.

There are other options. The best thing to do would be to set down
your actual requirements, and then see what technology best fits them.
For instance:

* Do you need programs running on other computers to be able to
send/receive messages, or just on the local computer (ie, do you need
network support)?
* Do you need asynchronous requests/responses?
* Do you need to support multiple simultaneous requests?
* Conversely, must you explicitly forbid requests when another app is
using the API?
* Do you need to move significant amounts of data around, or could it
all be done with simple 32-bit integers?

If you need networking, far and away the best option is TCP sockets.
But your post suggests that something light-weight is what you're
after.

If you don't care about return values, or alternatively if you can
return an instant response, it might be easiest to simply use window
messages. You pass in a message number and two parameter integers, and
you get back a returned integer. That's enough for a lot of things,
but you have to be able to return very quickly.

You may wish to google for 'Windows IPC'; there's quite a few options
available. Deciding which one is best for your situation is partly art
and partly science... and partly faith in the future. I recommend
choosing the one that looks like the coolest and most fun to play
with; that way, even if the project fails, it's not been a complete
waste.

ChrisA