Exposing COM via XML-RPC or Something Else

[Samuel A. Falvo II]

In article <snipped for SLRN's sake, see below>, Brian Lloyd wrote:
Message ID: <613145F79272D211914B0020AFF6401914DD81 at gandalf.digicool.com>

>> Highly satisfactory.  Now all we need is a truly open COM 
>> implementation.

I'm working on that right as we speak.  I know the COM 0.9 specification on
Microsoft's site is old, but it does serve as a useful foundation upon which
a more modern COM implementation can be made.  In fact, I'm stratifying the
COM specification into two major levels:

Level 1: Generic COM, or GCOM for short.  This is the absolute minimum COM
implementation possible.

Level 2: GCOM Basic Services.  These provide support functions and
interfaces for things like monikers and other 100% Windows-independent
things.  As much as I hate to say it, this does NOT include uniform data
transfer, as that uses a lot of data structures and definitions found in the
Windows API.

Anything above this, as far as I'm concerned, is implementation-specific
stuff (for instance, one can conceivably make a Windows-compatible COM
library which implements the Windows-specific stuff on top of GCOM level 2).

>Maybe not - IMHO SOAP is a good step forward, since you will
>now be able to just implement SOAP-aware Python objects instead
>of mucking around with COM. You can still interoperate with 
>existing COM objects - hey, you could even declare them to be 
>"legacy" code :^) 

No way.  COM is contemporary, not legacy.  And even then, it fills a very
different need than the academically correct "object oriented" systems such
as Python.  I foresee a use for both types of objects for a long time to
come.

For example, the in-house work I'm doing for my company can make far, far
better use of COM objects than the traditional notion of objects.  Which is
why I'm working on porting a minimal compliment of COM to Linux.  :-)

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