Re: A UUID function for web developers

"ISHIKAWA,chiaki" <[email protected]>
Newsgroups gmane.comp.mozilla.devel.seamonkey
Message-ID <[email protected]>
On 2016/03/18 7:16, [email protected] wrote:
> they must conform to certain standard such that no two will ever collide.

"no two is ever likely to collide" is best we can hope for, BTW.

You can write, as some suggested, a uuid function by picking up one of the algorithms from, say,
https://www.ietf.org/rfc/rfc4122.txt

The beauty of uuid is that, because there is no central authority,  anyone can generate one and use it for one's application domain as one sees fit albeit a very, very  small probability that in one's application domain when IDs from similar applications are collected, that a collision *may* occur, but to an ordinary user, one can neglect that.
(The collision is so unlikely in ordinary use that if one finds an instance, I would think that should be put on the wall on a plaque :-)
But at least, EVERYONE should use a reasonably good uuid implementation that uses  something like one of the algorithms in rfc4122 with enough care.

Just my two cents worth.

PS: A malicious user can create, of course, create data with uuid to cause trouble in an existing application domain with existing data with published uuids [I mean it is a simple act of copy&paste], but
if one cannot stand that behavior in an application domain then it is time for a centrally managed id system (and some manners of preserving the authority of the assignment with all the management and security overhead of such a centrally managed system. It *IS* a trade-off to use uuid for care-free creation and assignment (assuming we have a good implementation of uuid creation function which every application user in that domain agrees to use.)

E.g.: I have seen uuid used for real and virtual disk volume ids and have not heard of a collision before. And *IF* by sheer chance (1/2^n), uuid collision occurs the worst it can happen is that an OS refuses to mount the second system with the same uuid, and one can always regenerate a new uuid to the second disk (and hopefully the newly generated uuid won't match another uuid in the system) and mount the disk with the new volume id.
If someone's application is doomed if there are different data with the same uuid, then the use of uuid is fundamentally flawed. There has to be a mechanism of soft-failure and recovery path.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.