I think what makes the GUID spec so bewildering is the fact that GUID
needs are highly application-specific.
Your point is actually right on target. GUID generation is non-
perfect and probabilistic. Just generating random data isn't really
conceptually any worse, it just gives a much higher probability of
conflicts, since random number generators aren't pure and can be
influenced by things like the random seed, different machines, system
shutdowns, etc.
What the GUID spec does is create a system in which it's practically
impossible (as opposed to theoretically impossible) to generate the
same GUID twice. In order to do this it basically calls on a handful
of different unique data and mashes it all together. It also strives
for variation (since checking the IP address has nothing to do with
generating a random number, for example) so that there is no one
point of failure. But in the end, it's just the difference between
"unlikely" and "super super super super super unlikely", and really
it's the application that is going to define how many "super"s you
need =).
For the vast majority of applications, an incrementing counter or
timestamp with a little app logic is all you need to get unique IDs
for your uses.
From what I can dimly understand of the various versions of the
spec, there are time-based, name-based and random-based versions.
All of them are built from 1 x 60 bit value, 1 x 14 bit value and 1 x
48 bit value, plus 4 bits for the version id, and 2 bits for the
'variant' (I haven't worked out exactly what that is, but apparently
it should be 1 0.)
In the random version, each of these values (apart from the version
and variant) is generated randomly, or pseudo-randomly.
So my naive question is, for the random version, what would be wrong
with simply generating a random sequence of 128 1s and 0s, sticking
the version and variant bits in the right places, and then
baseConverting the whole thing in groups of 4 to Hex digits. Add the
formatting dashes, and it's done.
This is probably very naive indeed, perhaps someone here understands
the issues well enough to comment.
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
