Gene Heskett wrote: > On Tuesday 15 March 2016 19:55:52 Chris Angelico wrote: >> On Wed, Mar 16, 2016 at 10:38 AM, Thomas 'PointedEars' Lahn >> > And as for second-level domains, consider for example “t.c” instead >> > of “twitter.com” as part of the short URI. >> That'll work only for the ones that you code in specifically, and >> that's only shortening your URL by 8 characters. A typical URL needing >> shortening is over 80 characters - maybe several hundred. You need to >> cut that down to a manageable length. That fundamentally cannot be >> reversed without readding information. > > And I submit that putting someone in charge of the drives organization, > and the database on that drive that the url has to dig thru, can make a > huge difference in the length of the resultant url.
Maybe it’s just the late/early hour, but you’ve just lost me. Please elaborate. >> >>> And with the exception of Twitter-ish sites that place a limit on >> >>> message length, there really is *no need* for shorter URIs >> >>> nowadays. (HTTP) clients and servers are capable of processing >> >>> really long ones [1]; electronic communications media and related >> >>> software, too [2]. And data storage space as well as data >> >>> transmission has become exceptionally inexpensive. A few less >> >>> bytes there do not count. > > They may not count for that much in terms of what the user pays for > bandwidth, but see below. And some users are probably still paying for > their internet access by the minute in some locales. So they should loathe more the overhead measured in *kibibytes* and delay measured in *seconds* caused by additional HTTP requests due to redirection from “short URLs” than the few more *bytes* in longer, original URLs, yes? -- PointedEars Twitter: @PointedEars2 Please do not cc me. / Bitte keine Kopien per E-Mail. -- https://mail.python.org/mailman/listinfo/python-list
