Re: Proposal for GUID datatype

On Sat, Sep 09, 2006 at 08:29:16AM -0400, mark(at)mark(dot)mielke(dot)cc wrote:
> On Sat, Sep 09, 2006 at 07:06:23AM -0400, Jan de Visser wrote:
> > On Saturday 09 September 2006 01:33, mark(at)mark(dot)mielke(dot)cc wrote:
> > > I don't think so. If it isn't 128 bits - and you want to fit it into
> > > 128 bits, it means padding. Where should the padding go? As application
> > > specific, it is up to the application to convert.
> > I am not saying that. I am just saying that you shouldn't limit yourself to
> > any particular input formats. I understand that the example I gave is not a
> > full GUID. As I said, I use that result as a base for a 128 bit GUID.
> > Aargh.
> ...
> It ignores punctuation - great - so now what? You provided a number that
> used an odd number of hexadecimal characters, that was less than 128-bits
> worth of data.
> Exactly which 128-bit value would you expect it to represent? Where does
> the padding go? The beginning? The end? Around the punctuation? When you
> say you use it as a base - what do you mean, and may your intention match
> the intention of anybody else who wishes to stuff a non-UUID into a UUID?

I'll be more specific, because I obviously wasn't getting through before.

According to the JavaDoc, it is:

32-bit int process identifier
64-bit int time identiier
16-bit int counter

If non-standard, and possibly allowing for overlap with a standard UUID,
I believe this could map to a UUID.

The 32-bit value would fit where a random number or MAC address is
normally represented as a 48-bit value. Some 16-bit prefix, possibly
all-zero might be used. The 64-bit value would fit where the time
value is normally put into the UUID. The counter could be where the
counter is normally put. A somewhat compatible version number could
be put in the version number part.

You see now? Punctuation is actually *significant* in this case, but
only the Java RMI libraries know what the value represents, and how it
might be mapped to UUID. If you look at your original value, you
should note the odd number of hexadecimal characters. This probably
means leading zeroes were stripped, and they would need to be restored
in the correct place. This is intimate knowledge of a very specific
UID type, with a specific number of bits, and automatic conversion to
a different UUID, with a greater number of bits, where the bits are
in the wrong order and not properly padded if interpretted raw.

Make sense now?

Cheers,
mark

--
mark(at)mielke(dot)cc / markm(at)ncf(dot)ca / markm(at)nortel(dot)com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/