Re^3: Long url to tiny url.

If you just issue the next available alphanumeric sequence, as you say, the URL is always as small as possible. But the problem with that, or any other predictable sequence, is that it's open to abuse. Conversely, if you use a random number generator with a short period, as you say you'll get lots more collisions, while a long period means the URLs will be longer than necessary.

Polonius

Comment on Re^3: Long url to tiny url.

Replies are listed 'Best First'.
Re^4: Long url to tiny url. by almut (Canon) on Jul 07, 2007 at 16:10 UTC
Good point! (It always surprises me how you monks can turn anything into an interesting discussion :) Another way to deal with the problem of predictability would be to apply some 'salting' mechanism. For example, in its most simple case, prepend (or append) a random digit to the number, and use that to XOR the other digits (many other algorithms are conceivable, of course). That would considerably reduce predictability, while retaining most of the desirable properties of the simple counting approach. Yet another way would be to just check every tinyURL against a list of potentially vulgar or otherwise abusive words, and, if found, just skip that particular tinyURL. The advantage of that would also be that innocent users of the service wouldn't accidentally be assigned URLs, which might require them to add apologies or further explanations when sending out such an URL...	[reply]

Replies are listed 'Best First'.

Re^4: Long url to tiny url.
by almut (Canon) on Jul 07, 2007 at 16:10 UTC

Good point! (It always surprises me how you monks can turn anything into an interesting discussion :)

Another way to deal with the problem of predictability would be to apply some 'salting' mechanism. For example, in its most simple case, prepend (or append) a random digit to the number, and use that to XOR the other digits (many other algorithms are conceivable, of course). That would considerably reduce predictability, while retaining most of the desirable properties of the simple counting approach.

Yet another way would be to just check every tinyURL against a list of potentially vulgar or otherwise abusive words, and, if found, just skip that particular tinyURL. The advantage of that would also be that innocent users of the service wouldn't accidentally be assigned URLs, which might require them to add apologies or further explanations when sending out such an URL...

[reply]