Python COM and distribution issues

[David Bolen]

hungjunglu at yahoo.com writes:

> Thanks, but I don't think I misunderstood the GUID generation 
> mechanism. 128 bits are 128 bits, and I think you did not understand 
> that part. 128 is a finite number. It's large enough that people do 
> credit card transactions over interenet (high-encryption keys). But 
> it's a finite number. There are no magic in computers. A finite 
> number is a finite number. 

True, but just as technology significant advanced can appear as magic,
a number large enough can appear as infinite :-)

> As Mark Hammond mentions again and again in his book: "do not copy 
> this GUID, generate it instead by using pythoncom.CreateGuid()" OK, I 
> guess what he means is that it's OK to hard-code the GUID numbers, 
> but generate them each once using pythoncom.CreateGuid(), and then, 
> as I said before, just sit and hope for the best.

Yes - CreateGuid() calls the Win32 API CoCreateGuid() (same as the
command line uuidgen tool does), and returns a value that with a very
high degree of certainty is globally unique in both time and space.
It implements the OSF DCE algorithm for generating that id.

It is true that if you have a choice between a machine with an
ethernet NIC or a machine without, that you're better off generating
the GUID on the machine with the NIC, as its globally unique MAC
address (as established during manufacturing) is incorporated into the
process.  On a non-NIC machine, the algorithm works hard to make the
probability of a collision very small (it synthesizes an equivalent
NIC based on volatile machine state), but it is not as good as a NIC
machine.

Is there still a non-zero probability of a collision?  Yes.  But is it
some ridiculously low chance?  Yes.

There was an Internet-Draft (that was since allowed to expire) written
by Paul Leach at Microsoft and Rich Salz at Cisco that documented the
algorithm and provided some analysis.  Today you'd probably have to
find information at an ISO or DCE document site.  Essentially, it
shows that in the ethernet NIC case, the created UUID/GUID is
guaranteed to be unique until at least 3400 A.D., or otherwise is
extremely likely to be different.  The algorithm supports generating
millions of ids per second on a single machine uniquely.

The guarantee in the first case is the global uniqueness of the MAC
address on the NIC, so I'll probably agree that a mistake during
manufacturing could affect that probability.

But to be honest, there are far more worthy things to worry about when
writing a COM application than the uniqueness of the generated UUIDs
:-) (Especially given that the entire COM universe, not to mention
other application environments needing a distributed global
identifier, sort of depends on that, and it hasn't collapsed yet)

> Now a more serious question: does anyone know how to distribute an 
> application containing a PythonCom server component?

I believe that was asked recently and both py2exe and Gordon's
installer package weren't quite possible yet, but at least Gordon had
replied saying he was looking into it since he would likely need it
himself in the near future.

> Right now it seems like the only practical way of distributing Python 
> COM server applications is to install a whole copy of ActiveState's 
> Python distribution, and install the rest on top of it. This is not a 
> nice way of distributing your applications.

It probably doesn't have to be that difficult - just pull the package
together with one of the packagers, and then combine it with a free
installation package like InnoSetup.  The installation package can
handle placing the right DLL files into your system directory as well
as registering either them or the COM classes (by running your
application to register itself).

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/