Short URL hints / autodiscovery RFC
sites.google.com
Love it or hate it URL shorteners are here to stay. Here is a draft proposal for a simple spec that would allow them to play nice with sites that already have their own short URLs
sites.google.com
* It takes bandwidth
* It's (presumably) before a pageload, and is blocking... the latency to load the original URL to get the "link" gets added to the consumer's pageload time.
* Now you have to deal with "timeouts"
Ideally, "link" should be used by the browser, and not the web service. By the way, other such auto-discovery systems are OpenSearch (first proposed by Amazon, and is pretty widely adopted) and FavIcon.
At any rate, I think tinyurl, and bit.ly, etc, are a pretty fast and easy solution at this point. They should improve their services by including a "title" attribute to the link they give you, which says the URL and/or page title it's going to.
good point about the bandwidth and timeouts.
also, browsers could definitely use the link information. Thought the idea is for the twitter clients (and other micro-blogging tools) to not obfuscate a URL with shorteners in the 1st place.
granted some sites will always need tinyurl.com, etc but there should be a way for sites to specify their own short URL versions of their long URLs
also as i understand it, adding a title attribute would break the purpose of using a URL shortener - i could see the link with title would take up more space than the original URL in HTML code.
also thanks for the opens search and fav-icon suggestions. i will update the RFC.
I always thought URL shortening was just to make the HREF short... not the source HTML.
"shortlink (http://code.google.com/p/shortlink/) doesn't have any of the disadvantages of its predecessors...
Sam
the rev attribute is deprecated from HTML5