Python COM and distribution issues

[Robin Becker]

In article <mailman.989820402.30476.python-list at python.org>,
hungjunglu at yahoo.com writes
>Python COM seems to aim for single-machine software design, because 
>in all the examples I have seen the _reg_clsid_ are ALL hard-coded by 
>hand. It's 128-bit all right, but how can anyone be absolutely sure 
>that it won't cause conflict on different machines?
>
>It is unrealistic to distribute Python modules and expect the users 
>to perform pythoncom.CreateGuid() and modify the _reg_clsid_ in all 
>the program files.
>
>(1) How do people handle the GUID problem? Or do people just hard-
>code the GUID and hope for the best?
>
>(2) Has anyone done Python COM utilities for distribution? How do 
>people handle the GUID (Globablly Unique ID) problem? Has anyone 
>packed Python COM utilities into stand-alone executables (a la 
>py2exe)?
>
>(3) I tried to generate GUID dynamically instead of hard-coding, but 
>it broke PythonCom badly. In particular, the object browser does not 
>work anymore, and the whole operating system crashes when using 
>Python COM server objects from Visual Basic. Has anyone had similar 
>problem? If so, any pointer to the solution? If a class is registered 
>or unregistered a few times under different _reg_clsid_, does 
>something in the registry get corrupted? Where is a good starting 
>point to fix these problems?
>
>thanks,
>
>Hung Jung
>
>
>
I think you misunderstand the GUID generation mechanisms that M$
provide. By including various probabilistic arguments and values
unlikely to be common to more than one CPU M$ claim in 'GUID Creation
and Optimisations'

'''
GUID Creation and Optimizations
Because a CLSID, like an interface identifier (IID), is a GUID, no other
class, no matter who writes it, has a duplicate CLSID. Server
implementers generally obtain CLSIDs through the CoCreateGUID function
in COM. This function is guaranteed to produce unique CLSIDs, so server
implementors across the world can independently develop and deploy their
software without fear of accidental collision with software written by
others.

Using unique CLSIDs avoids the possibility of name collisions among
classes because CLSIDs are in no way connected to the names used in the
underlying implementation. So, for example, two different vendors can
write classes called "StackClass," but each would have a unique CLSID
and therefore could not be confused.

COM frequently must map GUIDs (IIDs and CLSIDs) to some arbitrarily
large set of other values. As an application developer, you can help
speed up such searches, and thereby enhance system performance, by
generating the GUIDs for your application as a block of consecutive
values.

The most efficient way to generate a block of consecutive GUIDs is to
run the uuidgen utility using the /n switch, which generates a block of
UUIDs, each of whose first DWORD value is incremented by one. (For more
information on using the uuidgen utility, see "The uuidgen Utility.")
'''
 
-- 
Robin Becker