> > Hi!
> >
[quoted text clipped - 5 lines]
> What exactly are you trying to do? I cannot think of any use for such
> a thing as a unique id in Mac OS 9.
I can think of dozens, perhaps even hundreds, of situations, most of
them involving inter-machine communication, where a truly unique ID
isn't only a good idea, it's absolutely critical.
> If you are trying to do some
> interapplication communication, you should be using AppleEvents, where
> you don't need such a thing. And all other APIs don't need such a
> thing either. So in order to gives you a good hint, knowing what you
> are trying to use the id for would really help.
Not really - Just tell 'im how to do what he wants. Or show him a tool
that will do it for him. This ain't about religion, guy. It's about "he
wants this", not "he wants what you decide he wants". What he wants to
do with it is irrelevant.
> And if you just need an id inside you application, won't someting
> along the lines of
[quoted text clipped - 8 lines]
>
> Thorsten
It MIGHT work for him, but if he ever hooks up to a network that's
expecting a TURLY unique ID, it's a very real posisbility that this
hideously bad practice of faking a unique ID will kill the rest of the
network. And without question, if I ever came across a program that
wanted a GUID/UUID and found out it settled for that bit of code you
suggest, I'd be dumping that app faster than you can say "Begone!".
The whole point behind a GUID (Globally Unique ID) or UUID (Universally
Unique ID) is that the identifier is indeed unique - not just unique to
the machine the program is running on, but unique across every group of
machines it might have contact with. When done correctly, it should be
either impossible (or as close to it as can be practically measured) for
any machine anywhere on the planet to come up with the same GUID/UUID.
In certain networking situations, this isn't just important, it's
absolutely critical to keeping the network from exploding in your face
when an identifier collision happens. In others, it's just a handy "tag"
to refer to a machine (or even a process on a machine) by, but it's just
as important that you not "cross up" two IDs if you want the system to
keep functioning.

Signature
Don Bruder - dakidd@sonic.net - New Email policy in effect as of Feb. 21, 2004.
For info on this, see <http://www.sonic.net/~dakidd/main/contact.html> Short
form: I'm trashing EVERYTHING that doesn't contain a specific, rotating phrase
in the subject line. Sorry, but spammers have forced me to take this action.
Thorrsten Froehlich - 24 Feb 2004 00:27 GMT
> I can think of dozens, perhaps even hundreds, of situations, most of
> them involving inter-machine communication, where a truly unique ID
> isn't only a good idea, it's absolutely critical.
He did not say anything about the desired application area of the
unique id. This is your assumption.
> > If you are trying to do some
> > interapplication communication, you should be using AppleEvents, where
[quoted text clipped - 6 lines]
> wants this", not "he wants what you decide he wants". What he wants to
> do with it is irrelevant.
All I am doing is asking what he needs it for. Without that
information it might just be that he is porting something and does not
know about some unique Mac OS functionality that will allow him to do
the same job. You assume he wants to do something over a network, and
suggest half a megabyte project. Obviously, if he just needs a local
unique id that would be overkill. I don't understand why you jump the
gun with your "This ain't about religion, guy." - I find it offending.
> > And if you just need an id inside you application, won't someting
> > along the lines of
<snip>
> It MIGHT work for him, but if he ever hooks up to a network that's
> expecting a TURLY unique ID, it's a very real posisbility that this
> hideously bad practice of faking a unique ID will kill the rest of the
> network.
Well, did I even remotely suggest this would be suitable for network
use? I think "id inside your application" is a really clear
statement!
Thorsten