Well, if you happen to be stuck on Win32 and don't mind portability, you can
use the CoCreateGuid function of the Win32 API.
---
use Win32::API;
sub get_guid {
if (my $api = new Win32::API ('OLE32', 'CoCreateGuid', ['P'], 'V')) {
my $ptr = pack 'LS2C8';
$api->Call ($ptr);
sprintf '%08x%04x%04x%02x%02x%02x%02x%02x%02x%02x%02x', (unpack 'LS2C8',
$ptr);
}
}
---
I haven't had a dupe yet and it works great under the environments I have
tried (CGI, ASP, PerlIS, PerlEx).
The next time I have a compiler handy I'll be sure to check out Data::UUID
though.
Peter Guzis
Web Administrator, Sr.
ENCAD, Inc.
email: [EMAIL PROTECTED]
www.encad.com
-----Original Message-----
From: Gunther Birznieks [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 27, 2001 3:41 PM
To: [EMAIL PROTECTED]
Subject: UniqueID generation was Re: [Templates] Weird errors when using
caching...
I apologize in advance if this post makes some bad assumptions (so please
pick away!) because I am not familiar with the TT caching algorithm
assumptions. However, I did want to discourage the use of $$ one more time
before it gets too late because I know the majority of TT Users are
probably Unix guys who may not be familiar with the issues on Win32.
---
The PID is way more unreliable on Win32 systems. $$ gets reused very very
quickly (or sometimes completely reused) on Win32 ISAPI Perl.
Even if you base it off of a timestamp (or a second) you are going to have
problems.
Also consider mod_perl 2.0, if the multiple perl interpreters re in a
thread (same with ActiveState PerlEx) you will definitely have the same
process ID being shared amongst the round-robined threaded interpreters.
I am not sure if Data::UUID as mentioned previously here works well in such
an environment or not.
Jeffrey Baker's algorithm for determining a session id in Apache::Session
is mostly OK, but under ISAPI Perl still will come up with alternate
session ids unfortunately. So on Win32, you need some way of basically
making sure if the file already exists when you start writing, that you not
write over the file and instead maybe add 1 to some value and then try to
create a new filename and so on until a unique file ends up on the systme.
Note that creating a unique file of course is a bit easier than creating a
unique id because at least you can take advantage of the file system know
what's been created previously in order to avoid collision (the
create/exclusive flags).
Anyway, whatever method you choose, I just request that you don't use pure
$$ for the above reasons. Or at least allow ID generation to be plugged in
with a strategy object so it will be easier for someone who runs into
problems to plug in their own ID generation strategy. The interface to such
a thing can be quite simple (we use the strategy pattern for id generation
in our extropia libraries include Counter, Random, Process, TrueRandom,
Composite (which can take many of the above), as it really depends.
There are a lot of nice things about a pluggable strategy object for id
generation. For example, in debugging, I find using a counter strategy for
generating unique ids to be really nice because of the incrementing id is
easy to keep track of sequencing what happened and when something was
called. Especially for session generation. But then in production, you use
a real random session id generation technique for added security and
non-guessing.
Anyway, in summary I leave it up to you, but please don't take $$ at it's
pure face value unless there is a reason you won't run into the Win32 or
the PerlEx or mod_perl 2.0 scenario...
If Data::UUID works well under Windows and under UNIX and will work with
multi-threaded interpreters, then that would be fantastic. Also, is
Data::UUID compiled? This may, again, be annoying for Win32 users waiting
for a PPM database to update if it's not there.
Anyway, I am typing this message on a 20k modem line otherwise I would be
investigating these options more thoroughly before posting rather than
leaving the options open. Sorry about that...
Later,
Gunther
_______________________________________________
templates mailing list
[EMAIL PROTECTED]
http://www.template-toolkit.org/mailman/listinfo/templates
