-
Website
http://www.scripting.com/ -
Original page
http://www.scripting.com/stories/2009/04/03/joshIsRightUrlShortenersAr.html -
Subscribe
All Comments -
Community
-
-
Top Commenters
-
Popular Threads
All Comments
This doesn't really solve the URI shortener problem: if we turn some long URI into a URN, we have introduced new problems.
The solution is for everyone to stop making long URIs in the first place, and for places where long URIs are a problem to make them less of a problem.
Agree with Joshua about URL shorteners being a necessary evil.
Well, they are bad, especially when they get recorded as the only way to get to the end point, and then expire.
There needs to be link expanders which go out and read the HTTP 301 and then log/replace, repeat.
Dave, when it archives the tweets with OPML editor would you put in a link expander? :)
http://linkspander.appspot.com
Till then, for those into Django, the recently updated django-ittybitty allows you to host your own shortener and keep track of things: http://www.codekoala.com/blog/2009/mar/13/annou...
In the PHP world there's Phurl -- http://www.hido.net/projects/phurl/
The thing that needs to happen is the shortener service API has to be standardized so folks can write simple embeddable tags and bookmarklets without having to worry about the underlying service. Now if only there was someone out there who could design some sort of standard API...
but I also agree that they are a necessary evil and that, as Mojito adds, urls are probably becoming less and less relevant. How many people already type the name of websites into Google to find them?
My bet is that very soon, the first browser with just a "searchbox" will appear...
Shouldn't we add the Digg toollbar to this discussion as well?
I think Facebook is going to be the real Twitter when all is said and done. Not a popular argument in this crowd perhaps but thats where the updates are happening.
Irregardless, I hope Google doesn't buy Twitter and leave it to die.
for instance...
Original
"Check out this post from engadget http://sma.ll/8Hguf" (i made that shortener up)
New
"Check out this post from engadget [link]"
David. ^_^
No it won't. Links rot all the time; the web survives.
(And I don't believe "a large part" of the web is built on short URLs, either. It might seem that way if you live on Twitter, but I don't and I don't see short URLs often.)
Cheers.
*Lets start from the position where we don't put URLs up on a pedestal that need to be treated with religious deference --- the importance of pure URLs to users has been diminished -- in Japan advertisers don't include the URL on their billboards its simply go and Search for "Z"
* I would suspect that 80% or more of the non-spam URLs are generated by fairly reliable services e.g. TinyURL (been around for at least 8 years). Rather, what we may have is a situation where one or two services are too big too fail.
*By dismissing shortened URLs we are dismissing an idea that has been around in the physical world for 100+ years - you can buy a P.O. Box from USPS which redirects people to an alternative address. Do we really think that such a service should not find its way onto the web in some form.
*Applications that auto-generate URLs need to do so with caution (use reliable Tiny URL service) --- just as you wouldn't
use a third rate ISP or develop on a 3rd rate platform so to you shouldn't publish shortened URLs from unreliable or unproven services.
*Google and most other search engines practice some form of URL shortening in search ads: There is a display URL which is usually very different from the destination or landing page URL --- and when a user clicks on the display URL a Google URL is called. So on the one hand we are not being entirely forthcoming with the user about their destination and secondly Google is sitting in between the URL on the page and the destination much like these URL shortening services do.
We can reduce the one point of failure problem by having two short URLs. Web search engine AAfter.com already creates two short URLs at a time. Please, try us out, and give us feedback. We also have no problem to share our short url [aafter.us] database with any open source community. However, I am not following how 'use our own domain name' is going to work technically unless those domain points to our DNS server or every domains' .htaccess file is updated. Am I missing something?
But the thing is, is that I don't 'store/change' the link in the database itself (as twitter does). So if I decide to switch http://urlb.at off, or it's down, the original links pop back into the descriptions. Also, when someone wants to edit their post, they see the original url they entered, not a shortened one.
Also, recently I have been running a script through my database to go and get the mime-type and title (if one exists) of every link it has. It's taking a while, but should be useful for things like search and in order to provide more info about the link being visited. (Though I haven't yet worked out exactly how I'll o that yet - probably from another parameter int he API.
By far the worst thing I have learned about creating one is the huge amount of spam links the API gets, many of which I have 'banned' in one way or another, simply returning the requested url to be shortened.
I built it orignally as an exercise. And since I have been recently improving it and adding the extra stuff like stats etc, I'm glad there's a discussion going on about it now. Here and on Joshua's blog.
If you still have a vested interest in http://bit.ly can you get that glue worked out with them?
Site owners will never know 'where' someone visited their sire 'from' as the HTTP REFERRER in their logs will only the show the shortened Digg url and not the url of the page the shortened link was clicked on.
I just tested it with a few shorteners, including my own.
I think this is really bad. And quite amazing for someone like Kevin (who is pretty smart) to do something like this.
Sure, the bar itself is quite cute with some cute features on it, but framing a site is the worst way possible.
http://wordpress.org/extend/plugins/short-url-p...
"PS: Twitter could fix this problem right away if they wanted to."
If Twitter adds URL shortening, it too creates a problem if Twitter were to die. And it's not just Twitter either, FaceBook status updates aren't exactly long either.
No, the best way, I agree with Dave, is to do it yourself. Don't rely on some third party to do it for you, with the added risk of Third Party turning either evil or belly-up. Now all I need to do is get me a shorter domain name. =]
Speaking of third-party evil: the Disqus comment box doesn't allow me to enlarge the comment field in Safari. Well, it does, but then it just gets bigger than the iframe box (iframe? didn't check) it resides in. Ugh. If I *were* looking at Disqus for commenting (I'm not), this would turn me off.
On the other hand, as I realised yesterday after posting my comment... How much of a problem WOULD it be if "shortening service X" (cli.gs in my case, I like the stats and the API) died tomorrow? I only use it for tweets anyway, and I consider tweets somewhat... let's say "temporary", anyway. If I want something to stick around, I'll post it to my blog; tweets are expendable.
So, Service X dies, heck, Twitter dies as well... How much do I lose in that case? Not that much, really.
Then the shortening and lengthening could be done locally.
If the algorithm was known, it wouldn't go away.
OK, data formatting is not my specialty, so maybe I'm all wet.
I'm as guilty as the next guy using them though. I try to avoid their use though when the tweet will be under 140 chars anyway.
Another solution would be for me to provide my own shortener as part of my blog. Perhaps a parallel domain, T.BB or some such.
At any rate, this will mostly fall on deaf ears. See my other comment about change.
Feel free to suggest new features and improvements (twitter: @haqu)