Python plugin

[Samuel A. Falvo II]

In article <Y$u7SGAdYae4EwJv at jessikat.demon.co.uk>, Robin Becker wrote:
>Don't get me wrong, but to attack me for saying I treat COM as too
>object oriented and then attack me for being an OO neophyte seems a bit
>silly. I'm from the fortran era, I treat COM objects as exactly that;
>blobs with interfaces, that doesn't mean I don't appreciate nice OO
>languages like Python. The reason I like Python is that it allows me to
>"just do stuff".

As indicated in the message, the text wasn't intended to be an attack on
you.  I apologize if it sounded like it did.

>As for openness I think having seen a lot of the process of DDE OLE OLE2
>COM DCOM COM+ from the outside makes me more than a little doubtful
>about commitment to open standards. I have to do other work, not become

DDE and OLE1 are jokes.  OLE2 is a known-proprietary API.  COM itself is
open.  DCOM is also open, as interoperability standards for them have been
published, and are free to be used anywhere.  The only problem with DCOM is
that they are documented as a set of changes to the existing DCE RPC
specification, which means you also need the DCE RPC specification to
understand DCOM.  Warning -- it's a BBIIGG specification.  :)

COM+ is currently a proprietary extension to COM, but are nonetheless plain
ol' COM objects.  And they document most (not all) of the specs on their
MSDN website, so it IS possible for someone to implement much of COM+'s
capabilities without any special blessing from Microsoft.  In fact,
something tells me that MS would be very happy if you did support the COM+
APIs under other operating systems.

>an expert in all areas of CS. You have a special interest and expertise;
>please don't criticise me for not having the same. I won't slam you for

I didn't.  At least, I didn't intend to.  Again, I apologize for what
sounded like an attack.  It wasn't meant to be.

>not understanding linear algebra if you complain it's complicated. The

Linear algebra...piece of cake.  Don't waste my time with such silliness.
Now, 2+3 ... THAT is something I'm having major issues with... ;-)

>fact that a document describing the 'latest' version of the API is
>available doesn't change the complexity or otherwise of the API. M$
>describes the Win32 stdcall interface in about one page to someone who
>understands a bit about assembly programming. The equivalent for COM is
>how much?

Win32 stdcall interface is a calling /convention/.  It is not an API.  Note
the difference.  And all the stdcall convention says is, "The callee shall
remote parameters from the stack, not the caller."

Now, I might refer you to the Win32 SDK, which DOES describe the Win32 API.
Note how much bigger it is than the COM 0.9 spec.  (The 0.9 spec for COM
consists only of the first six chapters, to be pedantic.  The rest of the
document is a description of the various interfaces commonly used under COM,
but which themselves are not part of COM proper).

>I don't pretend to fully understand the various aggregation mechanisms
>in COM/DCOM even though the underlying technology is fairly simple. COM
>interaction with threading models in win32 is indubitably complex as are
>events, but that's probably inevitable given the various threading
>models. 

Yup.  In fact, I'm running into _precisely_ the same problems under Linux
with GCOM.  The problem stems from the fact that not all object
implementations are thread safe.  For example, if I write a COM object for
Linux using GCOM which provides an interface to the GTK library, no matter
how thread-safe I make the COM object itself, GTK just plain ain't thread
safe.  Therefore, the GTK COM object would need to sit in a single-threaded
apartment, while everything else can sit in a free-threaded apartment.

Other object systems exhibit similar threading architectures, though they
implement them differently.  The only reason I'm preserving the "apartment"
concept under the Linux version of GCOM is because Linux's thread/process
model is similar enough to the Windows model.  Dolphin's GCOM, however,
requires that _all_ loaded binaries be thread safe, so it doesn't understand
the single-threaded apartment concept.

>As for verbiage I guess that's a matter of style. Modern practice calls
>these things interfaces etc I come from an earlier era where callables
>were functions/procedures etc.

Individual methods are functions or procedures.  The set, specified
collection of functions is known as an interface.  Example: fopen, fread,
fwrite, fclose, fprintf, etc. all belong to the ANSI C file-handing interface.

-- 
KC5TJA/6, DM13, QRP-L #1447
Samuel A. Falvo II
Oceanside, CA