3 ms·
There are pigeonhole principle issues with the concept of url shortening - the same that apply to data compression in general. With regards to urls that are a
by jowiar 15y ago
There are pigeonhole principle issues with the concept of url shortening - the same that apply to data compression in general.
With regards to urls that are a bit of ways down the tree (http://www.foo.com/bar/baz/whatever http://www.foo.com/bar/baz/whatever), this isn't really an issue, as generally within a domain, the url-friendliness comes at an expense of a great deal of length, and you can do something like:
shortened url := http://short.nr/shorten(domain)shorten(tail) http://short.nr/shorten(domain)shorten(tail)
and end up with something shorter.
When trying to shorten already-short urls, though, characters will not necessarily be gained.
From Twitter's perspective, the ideal solution might be to count "urls" as a fixed length, or an attachment, with respect to the length of a tweet so as to sidestep this issue entirely.
- philh 15y agoIf all you want is shortening, then there shouldn't be a problem: if the t.co link is longer, just don't use it. This is different from data compression because "pointers are automatically dereferenced": there's no functional difference between t.co/foo sending you to google.com and t.co/bar sending you to t.co/foo. (If I'm wrong about this, then it's still possible to not-make-longer everything that isn't a t.co link.) A similar case with data compression would be if you can guarantee that the decompressed data is never a valid compressed file. In this case, compress something iff that makes it shorter, and decompress something iff it's compressed.