Slashdot Mirror
Can rev="canonical" Replace URL-Shortening Services?
Chris Shiflett writes "There's a new proposal ('URL shortening that doesn't hurt the Internet') floating around for using rev="canonical" to help put a stop to the URL-shortening madness. In order to avoid the great linkrot apocalypse, we can opt to specify short URLs for our own pages, so that compliant services (adoption is still low, because the idea is pretty fresh) will use our short URLs instead of TinyURL.com (or some other third-party alternative) replacements."
I read the first link, sounds like complete and total batshit paranoia. I can't be alone in this opinion. Really, tinyurl has been around the entire 11+ years I've been on the internet, and somehow the internet's survived just fine.
tag:slownewsday anyone?
What value are these new URLs if they aren't cute?!?
Seth
$5 / month hosted VPS on linux = awesome!
I didn't understand a single word of the submission, and I used to teach Web design. Is it too much to ask submitters to define terms they use?
what exactly is the point in URL shortening ?
the only argument I can see is publications and twitter
publications - there is no way that I am going to be able to example.com/typeskjd583 better than a URL this has been tried and frankly failed
twitter char limit - well actually twitter should solve this by offering their own service and key into what people are looking at thus having that knowledge inside twitter and being able to monitize it...
apart from those two reasons (which are false for I belive the reasons above) what other reasons are there ?
URL's are good because they are Uniform....
regards
John Jones
how about we just kill all twitter users instead?
http://developers.slashdot.org/comments.pl?threshold=2&mode=thread&commentsort=3&sid=1196477
Best Slashdot Co
How many recall such threats to the internet as the massive ascii storm caused by Cantor and Siegel and the like, or the sudden tsunami of traffic due to graphics being constantly broadcast by the world wide webby thingy?
Those and many other phenomena usually resulted in people running around with their hair on fire, flapping their arms and screaming DEATH OF THE INTERNET!
The majority of bandwidth is taken up by email spam and botnet traffic. Next to those URL relay traffic isn't even noticeable.
Film at 11.
"I may be synthetic, but I'm not stupid." -- Bishop 341-B
For when you don't even have the time to hear about Blogger, Wordpress, RSS, or HTML (let alone learn about 'em)!
You can hold down the "B" button for continuous firing.
isn't the limit mainly for its utilization of SMS?
Absolute power corrupts absolutely. indymedia
Yes, TinyURL hasn't killed anyone. BUT... any attempt to fix this is entirely missing the point anyway. From the article:
If they fix twitter to support links with proper labels or tag contents --- Oh, I don't know, like HTML has supported from the very beginning --- then there wouldn't be a problem.
Don't work around the bugs, fix the bugs. Links are designed for machines, the higher-level marked up text is for people.
Twitter is essentially an SMS aggregation and redistribution tool. SMS is limited to 140 character messages. I do not think you understand the meaning of the word "arbitrary".
I'm sorry, but why should I have to change my URL just because of twitter?
There's the 160 char limit of SMS messages and Opera Mini is limited to what, 214 chars for a URL? Or something like that.
Not my fault, and no reason I should fall within their limitations. Tell them to fix their side.
(note, someone who is getting really annoyed at some browsers suddenly having a limit to the length of a URL)
Linkrot happens when a URL shortening site (such as tinyurl) is pulled offline. Billions of dead links is not good.
On the Twitter /. feed, this of course shows as:
slashdot Can rev="canonical" Replace URL-Shortening Services? http://tinyurl.com/c3j4n8
P.S. Now if you want a really short URL, try http://tinyarro.ws/ (no affiliation; just impressed by the idea)
Any article mentioning twitter is nothing but fart-sniffing.
/. in last 12 hours which has something to do with twitter. They all have been equally pointless.
This is third article here on
I guess I'm stupid. Is there any reason not to have a nice neat hierarchy on the server, that is mirrored with a collapsed symlink farm, with the symlinks exposed in the web pages? Yes, this means one has to map the long names to the short names when generating pages, but that can be an authoring-time issue or dynamic page generation issue. Heck, output-rewriting of the page can do this.
In Liberty, Rene
It's "rel," not "rev."
Shop as usual. And avoid panic buying.
This is a phone-related problem. The basic problem is that URLs are being sent to devices that don't cut, paste, and bookmark. This is only an issue if you have to type the URL manually.
Maybe what's needed are smarter Twitter clients.
How about Twitter just stops arbitrarily limiting characters. Go by word count, perhaps?
I know some avid twitter users, and the majority of them apparently use the idiotic SMS message system to 'tweet' each other all throughout the day on their phones. Twitter can't abandon the 140-character limit for this reason.
For the record, I am against anything that keeps the SMS system relevant in this day and age. It should have been abandoned long ago in favor of standard data packets on the internet, rather than control packets on a proprietary wireless system. There's no good reason to keep this system alive when it either forces you to pay $X per month for it, or pay $.15 per 140 characters when one of your idiot friends 'texts' you. There's no way (that I know of) to force incoming SMS to route through GPRS, so you are hit with SMS fees even when you already pay for unlimited data. It also invites spam that you actually DO pay for, quite literally, and from which the wireless carrier profits as well. It should be illegal for the carrier to charge you for incoming SMS messages. Anyone who agrees with me should call their congressperson to protest this policy and call their wireless carrier to block all SMS messages.
idontthinkthatwillworkverywell.
Life is like a web application. Sometime you need cookies just to get by.
No one is going to make you do anything. This is completely optional. If you want to provide short URLs to your site, it's a way for you to do so without going through a third-party service like tinyurl. If you want to continue using long URLs, there's absolutely nothing stopping you from doing so.
Is there some particular reason why you don't want people to have a standardized way of providing short URLs if it doesn't affect you at all?
Instead of using a plethora of different URL shortening services, any of which might disappear at some point in the future, Twitter should implement its own URL shortening service (using, say, the domain http://tw.it/ or similar) and thereby shorten any URL's that Twitter users post. Assuming the Twitter team can manage this (given their track record with things like message queues, however...) then there would be no possibility of linkrot.
Unless you're using shortened URL's somewhere besides Twitter, of course. But why on Earth would you do that?
There's all this talk of URL shortening services - whether third-party, or in-house implementation.
The question here is this: Why are the URLs so long to begin with?
Why does it have to be:
http://shiflett.org/blog/2009/apr/save-the-internet-with-rev-canonical
A full title in the URL is, IMHO, a very inefficient idea. The excuses I've heard are:
Search Engine Optimizations (better performance when keywords are in the URL)
Okay, I can't argue that some search engines do stuff like that. But shouldn't the TITLE or META tags have more bearing on this than how ridiculously long the URL is?
"The URL has meaning, so you know what you're clicking", Context, etc.
I suppose that when I see a URL like
http://shiflett.org/blog/2009/apr/save-the-internet-with-rev-canonical
as opposed to something like
http://example.org/blog/526
I would have a slightly better idea of the article's content before clicking on it. But then again, I can't really say that I've decided against clicking on a link just because of the link URL. I would, instead, decide whether I'd want to visit the link by its link text/description.
So <a href="http://example.org/blog/526">blog on link shortening</a> would still have the same effect on me as a long URL IMO. If it were bookmarked, the same rules would apply.
Hell, if I were handed an obfuscated shortened URL without context, I'd know even less of what I was getting myself into.
I think the proper solution is to just stop making ridiculously long URLs to begin with, so we don't have to rely on obfuscation/hashing/shortening to accommodate services that have character limit restrictions. And we'd save bandwidth too, apparently. Win-win?
Here in Norway sending an SMS was approx. $0.15 five-six years ago. Today it's as low as $0.03 - depending on plan of course. Receiving has always been free, AFAIK.
And Norway is supposed to be a really expensive country. All that crap about US telcos must be true =)
The SMS system is kinda outdated though -- on new years eve, messages are often delayed for 30 minutes or more - I've gotten a 'happy new year' as late as 1:20
Here's the thing: it's not just the path that is the problem, it's also the domain name. You can shorten "/blog/2009/apr/save-the-internet-with-rev-canonical" to "/abc123", but if your domain name is something plus-sized like "rickosborne.org" or worse ... how much have you really gained?
It's a little helpful, but not really. What you've done is remove the little bit of semantic meaning from the link, all in the name of being able to ego surf easier. Huzzah.
LOL! Only in America, the free market bastion of the world, do you have to pay for incoming texts.
Free Manning, jail Obama.
"Because bigger is better, right?" http://www.hugeurl.com/
1999 called, it wants its charges back.
People pay for SMS in your country? Here even pay and go plans have unlimited SMS bundles.
And I can't even parse this statement.. "or pay $.15 per 140 characters when one of your idiot friends 'texts' you"
How can your friends make you pay for SMS? Do you have some way of sending bills over it or something?
It's a "reverse" 301/302 redirect. It's not telling the short URL where to find your long URL, it's telling your long URL where to find the short URL.
In other words, services like Twitter will see:
<link rev="canonical" href="http://mydomain.org/short" />
And it will actually post a link to http: //mydomain.org/short instead of your long domain name in its text.
All this short URL stuff sounds like some phishing scam if you ask me. Short cryptic URLs obviously exist to make me transpose a couple of letters or numbers and end up at some fake bank site. No, give me large detailed URLs so I can see those dead giveaways like pid=poor_sucker&sid=steal_credit_card_info !
Short URLs indeed... no thank you Nigerian scammers... I won't be transferring any large sums today!
On a serious note, why is this news exactly?
The problem there is defining words. If you use spaces as a delimiter, people will be forced to write posts like they would telegrams, with no particles, conjunctions or anything else to get in the way. The enterprising joker will simply replace every space in the Gutenberg version of War and Peace with an underscore, and flood the service.
You're lucky. I get "Happy New Year" a day late from my US friends (even taken into account the time difference)
Je ne parle pas francais.
I thought the real purpose of shorten URLs was to help all the memory-challenged people who go to Google to search for the website instead of typing a long URL into the address bar. :P
In the US, if someone sends you a text message, you have to pay for it, and if you don't have a plan each text typically costs ~$0.15
Unfortunately, it's not yet an integral part of web frameworks that I have seen. So I am adding it in a new web site I'm building. It means I have to add the feature to the web server.
It works like this. Every part of the web site code that builds URLs for the same site passes them first through the mapping logic. This basically builds an SHA1 checksum of the canonicalized URL string. Then it looks up the string in a fast database (I'll be using Berkeley DB for this). If it's already there, and is the same URL, it generates a new URL that references the checksum. If it was a different URL, it notifies me that it found an SHA1 collision. If not already there, it adds it. The original URL is thus replaced with the mapping URL.
Code added to the web server will be designed to detect checksum URLs. If it looks like one, it looks it up in the database to get the original URL, and proceeds with the request using that URL. Original URLs would still be processed as usual, in case they leak out, or are intentionally made to bypass the mapping for special purposes. Basically it's like a tiny URL service, but integrated without the need to do a redirect.
One thing I am looking at doing is shortening even these URLs, even though they should be short enough already. But this raises the chance for a collision to the point I'll need to add logic to deal with it. How I would do that is similar to a hash data structure collision, but by expanding on the SHA1 checksum by adding back digits that were removed to shorten it.
External URLs to other sites can be done the same way. This does add the extra redirection. I could limit the use of this only to long external links, since this being a web interface, should handle long external links OK. It could be an option.
now we need to go OSS in diesel cars
Because of this:
http://www.google.com/search?hl=en&lr=&c2coff=1&rls=GGLG%2CGGLG%3A2005-26%2CGGLG%3Aen&q=http%3A%2F%2Fwww.google.com%2Fsearch%3Fhl%3Den%26lr%3D%26c2coff%3D1%26rls%3DGGLG%252CGGLG%253A2005-26%252CGGLG%253Aen%26q%3Dhttp%253A%252F%252Fwww.google.com%252Fsearch%253Fhl%253Den%2526lr%253D%2526c2coff%253D1%2526rls%253DGGLG%25252CGGLG%25253A2005-26%25252CGGLG%25253Aen%2526q%253Dhttp%25253A%25252F%25252Fwww.google.com%25252Fsearch%25253Fsourceid%25253Dnavclient%252526ie%25253DUTF-8%252526rls%25253DGGLG%25252CGGLG%25253A2005-26%25252CGGLG%25253Aen%252526q%25253Dhttp%2525253A%2525252F%2525252Fwww%2525252Egoogle%2525252Ecom%2525252Fsearch%2525253Fsourceid%2525253Dnavclient%25252526ie%2525253DUTF%2525252D8%25252526rls%2525253DGGLG%2525252CGGLG%2525253A2005%2525252D26%2525252CGGLG%2525253Aen%25252526q%2525253Dhttp%252525253A%252525252F%252525252Fuk2%252525252Emultimap%252525252Ecom%252525252Fmap%252525252Fbrowse%252525252Ecgi%252525253Fclient%252525253Dpublic%2525252526GridE%252525253D%252525252D0%252525252E12640%2525252526GridN%252525253D51%252525252E50860%2525252526lon%252525253D%252525252D0%252525252E12640%2525252526lat%252525253D51%252525252E50860%2525252526search%252525255Fresult%252525253DLondon%25252525252CGreater%252525252520London%2525252526db%252525253Dfreegaz%2525252526cidr%252525255Fclient%252525253Dnone%2525252526lang%252525253D%2525252526place%252525253DLondon%252525252CGreater%252525252BLondon%2525252526pc%252525253D%2525252526advanced%252525253D%2525252526client%252525253Dpublic%2525252526addr2%252525253D%2525252526quicksearch%252525253DLondon%2525252526addr3%252525253D%2525252526scale%252525253D100000%2525252526addr1%252525253D%2526btnG%253DSearch%26btnG%3DSearch&btnG=Search
My blog
SMS messages are 140 bytes, 7-bit encoded, resulting in an availability of 160 characters.
They reserved 20 characters for twitter metadata (username, for one thing).
sic transit gloria mundi
A couple of good questions I have seen, and my best attempt to answer them:
1. Don't you mean rel? No, I mean rev. It indicates a reverse link.
2. Why not make your URLs short in the first place? I happen to like my URLs and have made them as short as I want them. They're only too long in some very specific use cases, like Twitter. I could just complain about Twitter, or I could support an idea that makes URL shortening suck less. I chose the latter.
Thanks for reading, and please do feel free to criticize whatever you think is wrong with this idea. I'd like a way to indicate a preferred short URL for my own stuff, and this seems like a pretty good way to do it that makes sense semantically and is easy to implement. For an ongoing discussion about adding an HTTP header to do the same thing (so that only a HEAD request is required), read here:
http://shiflett.org/blog/2009/apr/a-rev-canonical-http-header
Anyone who agrees with me should call their congressperson to protest this policy.
Or better yet, text them.
sic transit gloria mundi
Free, maybe; rational, sane, or fair, less so.
You can hold down the "B" button for continuous firing.
not a url issue. There's no reason they couldn't parameterize it with a more legible url like developers.slashdot.org/comments/119647 by parsing and then interpreting the url.
Quack, quack.
In some countries, people pay for recieving texts. In the UK, normally recieving texts is free, except some online services manage to charge you by sending you texts, not entirely sure how that works.
-- All your booze are belong to us.
US wireless carriers charge on both ends -- both the receiver AND the sender will pay the 15 cents per message, assuming neither one of them has an unlimited plan. I think this charge used to be 10 cents, but was raised to 15 cents last year. Or maybe it was 15 cents and was raised to 20 cents. I have no idea, but either way it is terrible. I think plans are typically $5/month for 200 'texts' or $15/month for unlimited.
And don't even get me started on MMS messages. I received my first MMS spam the other day. My first thought was "ooh, nice tits", but my second thought was "$#%&, I probably just got charged $3.00 for this spam!"
Of COURSE they can abandon it ... its simple: if you send in your tweets by SMS you have the SMS limit of 140.
... NOT.
If not
The rest i agree completely. I hate the SMS system and think it is a ripoff.
In Sweden we just pay when we send an SMS, and it has always been like that. We have never understood the backward system in the US.
Surely the author of that rant knows about dns cache ... your pc will only consult the NS for tinyurl, etc once per day -if at all- depending on how many of those you click on.
...
... you still would have the 140 char limit.
And if you click on them rarely the delay would be neglible, cos you only use them rarely
Plus this, interesting as it may be, still does not solve how to get a long url into a Tweet... it does not matter if Twitter can go look up the small URL on its own
In some countries, people pay for recieving texts. In the UK, normally recieving texts is free, except some online services manage to charge you by sending you texts, not entirely sure how that works.
It's a special service that you have to opt into; you really should know if you're receiving those things and there should be a simple mechanism to turn off reception of them again.
(There are anti-fraud mechanisms built in to the UK system, AIUI mainly a delay of several months between the message getting sent and the cash being disbursed to the sender. That means that if someone tries anything too tricky, the receiver can dispute the charges and the money can be stopped if shenanigans are detected on investigation.)
"Little does he know, but there is no 'I' in 'Idiot'!"
In the US some cellphone providers charge their customers for receiving SMSs. Yes, it's appalling, doesn't make any sense and it's mind numbing. Yet, that's the service plan they offer and that their clients agreed on. Poor bastards.
Slashdot, fix your code or at least hire someone who is competent at it to do it for you.
From what i read of the article the solution to make the link smaller is to add an HTTP header that points to another page on your site with a smaller URL which sends a 301 redirect HTTP header pointing to the page with the long URL...
:)
I guess I'm just stupid but can't you just make your URL shorter in the first place?
Don't people just copy paste any URL from their address bar? How's a fancy HTTP header is going to help that? me not getting it.
Long, ugly URLs are a result of the software and practices in use with the web server. I just started looking at PHP frameworks and began with Symfony, which I like though I had some setup issues. Symfony (and other frameworks and web servers, I'm sure) uses a method of "routing" and some other mechanisms in the framework to compose pages from several places and makes urls in the form of:
http://server[/appname]/module/action/<[param][,[param]]...>
Making for a URL more like: http://my.page.com/blog/read/new
Instead of http://my.page.com/blog.php?read=new&prev=42024
I have a cheap GSM phone on a $5 per month plan with expensive calls. My wife has a 3G phone with hundreds of dollars of calls packaged per month. When I want to speak to her I send her an SMS saying "call me" and she calls me right back.
Its not very elegant, but it works for me. Not interested in this twitter bullshyt though.
http://michaelsmith.id.au
Errm, you do realise some people want to *receive* tweets by SMS don't you?
Don't you wish you hadn't wasted 3 seconds of your life reading this sig?
So how did they even get the short URL in the first place? Doesn't that mean they're browsing the net on their phone? So why still use sms then? And why should twitter not just expand the url back to its old size/text? Are people reading twitter by sms, too? Though I guess on the grand scale of the universe, this really doesn't matter.
Fleur de Sel
I guess I'm just stupid but can't you just make your URL shorter in the first place?
That was also my first thought, well, my second thought. My first thought was "what does 'rev' mean?". Reverse? Revised? Whts wrng with usng full wrds?
It's similar in Europe once outside of your own country, you pay the international part of the call.
"The likes of Facebook and WhatsApp are free to those whose privacy is of zero value."
Because the long URLs actually have meaning, which the short ones shed in order to allow brevity.
It is pitch black. You are likely to be eaten by a grue.
How about Twitter just stops arbitrarily limiting characters. Go by word count, perhaps?
I know some avid twitter users, and the majority of them apparently use the idiotic SMS message system to 'tweet' each other all throughout the day on their phones. Twitter can't abandon the 140-character limit for this reason.
I think that's a BS reason for keeping a 140 character limit on twitter.
Let SMS's character limit limit only the SMS user's messages. Twitter can break up longer tweets into 140 character segments and send them as "part1" "part2" "part3"... to people receiving tweets via SMS.
I think that while that was a legitimate argument when twitter started, it's evolved into a different kind of service these days and most folks using their phone for twitter are probably using something like twitterberry as a client anyway.
People stare at me as if I'm crazy when I say I use firefox as my twitter client, just like I do for other websites.
Why do so many URLs look like RDBMs queries? Has someone been sold a bill-of-goods?
As for shorter URLs, they become much shorter minus the DB cruft. And then all it takes is a modicum of logic to form some durable system.
Some people cannot avoid flavor-of-the-month. Those people should not be making decisions with any sort of permanence or continuity.
More like 25c these days. Because obviously the telcos' costs are going up.
How are sites slashdotted when nobody reads TFAs?
140 / 8 = 17.5
here in england its usually 10p - 15p per text (if your on PAYG, contracts usually give your 500+ free texts per month)
17.5 bytes / 10p = 1.75 bytes per pence
1.75p * 1024 = 1792p
£17.92 per MB
SMS sucks...
It depends on how they got those long URLs. If the domain names themselves are that long, then perhaps people should shorten them. But what if the URL is something "deep" inside the directory structure? On my personal (not yet on the web) site I have
classes/mathematics/College_Algebra/Chapter-1/chap-1-5.xml
Coupled with a domain name, that could be a long URL. Nevertheless, I would like to retain it, as it expresses the organization of my site.
kill twitter!
digg
I can see why you would want this because of Twitter, but I agree with everyone here who say that site owners should work on shortening the actual URLs as well.
/foo/bar/
A good CMS should encourage URLs like www.somesite.com/foo/bar/ instead of www.somesite.com/category.pl?id=12345
- It's easier to remember
But a lot of visits these days come from search engines, which makes the URL less important.
- For those visitors who pay attention to the URL it can aid with navigation.
At least if your site is very well structured and your visitors agree with that structure.
- It's good for SEO
But as someone else wrote in a comment here, a really long URL with lots of keywords can be good for SEO but bad for the user at the same time.
- A meaningful URL will show up when you're typing in the address bar in modern browser
Helpful as long as you're not always using Google to revisit sites.
Lately I've grown fond of URLs like www.somesite.com/foo/bar/article-title-goes-here.html?id=6789 for a specific article. The id=6789 is there to make sure the article can be found even if the title is changed.
Anyway, there is a lot of work that could be done to shorten URLs and make them more readable for humans.
Suggestion for this Slashdot entry: http:///..org/09/04/12/1834205
10-15p per 140 bytes is more like £749 to £1123.50 per MiB.
Your link is wonderful. And indeed, as their page claims, even very ugly URLs become cute. This is really a web-transforming technology...
Using your own linkshrink you can only save on the path, not on the domain. http://mysite.org/shorty, for example, can be compressed another 40% to (working) http://y.ly/acs.
Twitter could just provide its own www.tinyurl.com service. That way the links only rot if Twitter rots, and it places the solution right next to the requirement. Simple.
Zen tips: Pay attention. Don't take it personally. Believe nothing.
In what backwards, idiotic country do you live, that you have to pay for RECEIVED SMSes? That's so wrong and upside-down, I have to wonder if it was designed by a metally retarded slug.
"The agriculture ministry is not in charge of Gundam" - Japanese ministry official.
Ahem... Your calculations are off...
Let's start with 160 characters, as they do send your username with the message, it should count. 7 bit characters, at 160 characters per message is
7 * 160 = 1120 bits per message. You want the price in megabytes, so we'll convert to that first.
1120 / 8 / 1024 / 1024 (twice because you're looking for MB, not KB) = 0.000133514 MB max message size.
At $0.15 per message, that works out to
0.15 / 0.00133514 = 1123.48 USD per megabyte. Of course, if you're in England, paying 15 pence (as opposed to cents) per message it becomes 1123.48 GBP.
SMS sucks orders of magnitude more than you though it did...
Yeah, but that's because you're using a national provider to redirect your calls, and he wants to be paid too. You're actually using three providers on each call.
Dilbert RSS feed
So, would this do anything to prevent dumbness such as http://tinyurl.com/c6p4yl ?
Well as you totally grokked it can you tell me - shouldn't the canonical link be placed in the rel attribute?
http://www.w3.org/TR/html401/struct/links.html#h-12.3.1 says that rel is for forward links and rev is for reverse links. Canonical is a forward link as it says the primary location of the information at this onward link is where the current information is derived from. A canonical page wouldn't link out to the duplicate non-canonical copy - though if it did then that would mean the non-canonical page could have a rev="canonical" attribute in a link there.
See eg Matt Cutts post from Google, http://google.com/support/webmasters/bin/answer.py?answer=139394&topic=15262 .
Strangely rel="canonical" gives far less hits on Google than rev="canonical" which strongly suggests I'm wrong. In which case I don't get it all.
But I'm confident, so I'll stick my neck out and say canonical only fits in the rel attribute of a head link element.
Seriously, when will we go back to solving problems that actually matter?
"I love my job, but I hate talking to people like you" (Freddie Mercury)
...I have to wonder if it was designed by a metally retarded slug.
No, not by retarded slugs, but for retarded slugs. It's just greed on their part, playing with the wallets of the retarded slugs willing to be taken advantage of.
Down With Slashdot BETA!!! I've been around the corner and seen the oliphant; you can only abuse me from your perspecti
sms has a reason of existence, it's network overhead is minimal, allowing the use of sms even in overloaded situations, or in places with low network coverage. For the rest I agree with you as in why the hell we have to pay the ridiculous amounts of money for this service.
molmod.com - computing tips from a molecular modeling
yep, messed up the Kb Mb conversion, still my general point that if the service provider ran a jabber server it would probably more efficient and cheaper...
maybe that is what they are doing behind the scenes and still charging the high prices...
This won't work because you're expecting everyone in the world to have a database of URL of pages they've never visited.
For an ISP to support this technique the service provider would have to do a proxy/HTTP hack on every request. That would be messing to say the least and could easily lead to ligation for 'controlling user's traffic.
I'm actually working on a Firefox plug-in that is a similar idea. Here how it would work:
1. You create a text file at the root of your domain called shortlinks.txt
2. Each short link would be formatted as such:
MyShortURL=http://www.mylongurl.com/sdfsd/432re/sdfd?q=1222533322154
IMoved=http://www.relocatedpage.com/NewLocation
3. Someone clicks on the link below, tries to find a match in the shortlinks.txt. If one is found, redirect as needed otherwise continue processing the link.
http://www.mylongurl.com/MyShortURL
http://www.mylongurl.com/IMoved
No complex database or HTTP hacking. You control EXACTLY what the URL is. You're always in control of where the visitor is redirected to.
You say things that offend me and I can deal with it. Can you?
OMG, splitting a tweet into multiple sms's would be unthinkable! oh the horror!
TIAEAE!
It wasn't even the Digg Bar exactly. Gruber didn't like it because of the obvious reasons (breaks bookmarks, history, hides the site, etc) but mainly because the DiggBar was turned on by default for all users. Other sites have things like the Diggbar, but no-one really complained about them because users had to turn them on by default.
If he alone had not liked it you would not have seen the rush to block it from all quarters. I as a user despised it myself, and am happy to see all framing mechanisms die a horrible death.
Shortening services that use a redirect, he and others have no issue with.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
How about Twitter just stops arbitrarily limiting characters. Go by word count, perhaps?
I know some avid twitter users, and the majority of them apparently use the idiotic SMS message system to 'tweet' each other all throughout the day on their phones. Twitter can't abandon the 140-character limit for this reason.
Or they could use a time-window to concatenate tweets. If their send timestamp is within 5 minutes then concatenate them.
Anyone who agrees with me should call their congressperson to protest this policy and call their wireless carrier to block all SMS messages.
Surely you should SMS your congressman?
PS: Congressmen can be male or female or of indeterminate gender they're still called "Congressman"
urls posted to twitter should automatically be converted to a shortened url supported by twitter themselves:
tweet: "check this out http://foo.com/bar/lots/of/crap.html?a=1&b=2&c=3..."
should appears as: "check this out http://twitter.com/$user/x"
(where x is an unique id)
there would be a limit on the number of urls encoded per hour
after a 24 hours or so, the urls would automatically expand in your tweet history.
additionally, you could list all the shortened urls you are provided and convert them to long urls manually.
I'm not convinced being short is that much of an advantage. Typing english words is not that slow and a sequence of english words that makes sense is likely much easier to remember than some meaninless alphanumeric code.
What is bad for usability is including lots of irrelevent (or only relavent for tracking users habbits) crap in a url. e.g.
http://www.google.com/search?q=BS+EN+60238&ie=utf-8&oe=utf-8&aq=t&rls=org.debian:en-GB:unofficial&client=iceweasel-a
The character encodings are irrelevent since the search terms as ascii. The source of the query is only relevent for tracking what tools people are using to search it doesn't provide any utility to the user.
We geeks can probablly work out how to trim that down to a more minimal url that works as needed ( http://www.google.com/search?q=BS+EN+60238 ) but ordinary people would just see a wall of meaningless text with thier query burried in it somewhere.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
IMO length is not the only important thing in making a url easy to type
For your example I would suggest something like
classes/maths/college-algebra/chapter-1/1-5.xml
Same basic structure A little shorter but far less annoying to type due to the elimination of pointless capitals and the consistant use of dashes where words need to be broken within a part.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
There's no good reason to keep this system alive when it either forces you to pay $X per month for it, or pay $.15 per 140 characters when one of your idiot friends 'texts' you.
It's not the problem of SMS, but your broken pricing system in the US.
Here in Europe the caller pays for everything. So if I send an SMS then I pay for it, not the person I send it to.
Why do you have it backwards? Fix that instead.
Concatenating messages is actually a standard GSM SMS feature and has been for a decade now: you write a message longer than 160 characters, the phone sends it as multiple messages and the recipient's phone assembles the messages back together. The only point where you notice something odd going on is at the receiving end, when there can be a couple of seconds delay before you can read more than the first 160 characters. Is the problem that they don't support this on US carriers?
Or, perhaps the simplest solution: talk Twitter into letting you use more than 140 chars.
"There's a new proposal ('URL shortening that doesn't hurt the Internet') floating around for using rev="canonical" to help put a stop to the URL-shortening madness. In order to avoid the great linkrot apocalypse, we can opt to specify short URLs for our own pages, so that compliant services (adoption is still low, because the idea is pretty fresh) will use our short URLs instead of TinyURL.com (or some other third-party alternative) replacements."
Don't read this more than once or you'll contract A.D.D.
War as we knew it was obsolete
Nothing could beat complete denial
- Emily Haines
Well, you are against it. I don't think that will stop the billions of people who have and use SMS access but don't have internet access. Poor rural farmers in developing countries who use SMS to get price information for their crops, reducing the potential for middlemen to gouge them out of food money for their kids (this is not an exaggeration). Young folks shouldn't share their lives with their friends by SMS because YOU pay rip-off prices? Bully for you. And, Mr. Rich Guy, most of the world also doesn't pay 15 cents to send or receive a message. Here in Indonesia I think it's less than 3 cents.
In fact, STFU.
The subject who is truly loyal to the Chief Magistrate will neither advise nor submit to arbitrary measures (Junius)
Before we fix short urls, why not fix email address dependency by using private/public key encryption to direct emails instead.. This way the email travels with your identity, not reliant on ip address..
To solve short URL's use a similar method..
So effectively something like a P2P search for identities, use multiple public key connections for source verification, like how certificate systems are used, to avoid man in the middle interception..
Just say no to license servers!!
The whole problem is the fact that search engines put weight on keywords in URLs. This has led to the horrible trend of every blog and news site making ungainly urls.
Ever look at the normal URLs on a site like engadget.com ?
Like "http://www.engadget.com/2009/04/15/20/80/News_about_URLs/URLS_on_the_interweb_are_too_long_-_Do_you_agree_news_at_11"
If search engines did not care about keywords in URLs sites would have no reason to do this and could revert to the old fashioned (and much more brief) "/article?id=" type of URL.
Assuming it works, of course. I got a text a couple of years ago telling me a friend had gone into hospital. Her verbose boyfriend failed to convey this in less than 160 characters, so it was sent as a two-part message, and only the second part arrived. Because he was in the hospital, he turned his phone off as soon as the message was sent, so didn't my call asking what the first part said. SMS is not 100% reliable, and sending multipart SMS multiplies the failure rate for any given message.
I am TheRaven on Soylent News
As I've explained in detail here and here, while the underlying concept is sound, the implementation has many problems:
- "rev" is deprecated in HTML 5, so essentially a non-starter
- "rev" and "rel" are easily confused - use the wrong one and you may well drop off the Internet
- messing with the canonical URLs is dangerous
- taking rather than giving canonical-ness is dangerous
- the solution can only work for one URL (the canonical URL itself), when there can be an infinite number
A *much* better solution is to use rel="shortcut" to specify a short (but not necessarily shortest or even shorter) URL. Other alternatives like "short" are ambiguous as to whether it is the URL or its target which is "short", and "alternate shorter" are just plain wrong.
Sam
LOL! Only in America, the free market bastion of the world, do you have to pay for incoming texts.
I don't pay for incoming texts and no I am not on any text plan.
...I have to wonder if it was designed by a metally retarded slug.
No, not by retarded slugs, but for retarded slugs. It's just greed on their part, playing with the wallets of the retarded slugs willing to be taken advantage of.
Ouch!!
"The agriculture ministry is not in charge of Gundam" - Japanese ministry official.
Disclaimer: I'm an author of a competing RFC so my opinions might be biased - although i hope my reasons are as rational as possible ;)
An alternate approach to this problem:
http://wiki.snaplog.com/short_url
Summary
Short URL auto-discovery is a simple way to link a long URL with a short URL. The following code should be placed in the section of the HTML page.
<link rel="shorturl" href="http://short.com/1234" />
or add the following to the HTTP Headers of the page
Link: ; rel=shorturl
In most real-world situations, the short URL then redirects with an HTTP code 302 to the long URL, but that behavior is not covered by this RFC.
That's it! :)
why not use rel="alternate .... "
Sam Johnson pointed out alternate doesn't make sense since it implies a link to same content but different format like PDF for example
why not rel="shortcut"
Shortcut in the web context not well understood nomenclature referring to short URLs (OK to define shortcut icons with rel="shortcut icon" though and if we wanted to follow that model we'd use rel="shortcut url", but that seems excessive)
Potential legacy code breakage as suggested by http://twitter.com/soypunk/status/1509403319
Also somehow shortcut seems like the wrong wording... implies a link that will bypass something ... a splash screen, etc...
why not rel="shorter" or rel="short"
Implies shorter version of the content
why not rev="canonical"
rev is absent from HTML5 and confusing with rel="canonical", breaks Google's proposed definition of canonical for search purposes.
why not rel="shorturi"
Part of making a new RFC to describe a simple concept is simple naming. People know that a URL is what's in the location bar in their browser. Besides we'd never see a URI that's not an URL in this context.
why not rel="short_url"
The _ is ugly.
Don't forget to include a shortened URL to this discussion so they can read all about it!
In my experience, capital letters don't matter to a web browser. That's more on the local side of the web server if you have a case-sensitive file system. I completely agree with you about the dashes and underscores, though.
In my experience, capital letters don't matter to a web browser
In my experience, capital letters don't matter to a web browser. That's more on the local side of the web server if you have a case-sensitive file system.
The web browser just sends the path you typed to the web server in the same case you type it. If your webserver has a case sensitive filesystem (e.g. you are on standard LAMP hosting) and you don't take special measures then a user forgetting to type the capitals will result in a not found error.
I've found it much easier to just avoid caps in urls (and other filenames for that matter) completely. That way your urls are simpler for users to type and you won't have problems when moving between case sensitive and case insensitive hostings.
Off the top of my heave i've come up with the following guidelines for nice URLs (not everything has to have a nice url, just pages people are likely to want to write down/read over the phone/memorise ). Do people here agree or disagree with them?
1: avoid using meaningless identifiers to reduce the length. While www.mysite.com/page123 is shorter than www.mysite.com/personal/electronics/pic it is much harder to remember.
2: avoid repitition e.g. use Chapter-1/1-5.xml Chapter-1/chap-1-5.xml
3: avoid unnessacerally long words (e.g. use maths not mathematics). maybe even
consider using abriviations.
3: avoid crap that is meaninless to the user. E.g. www.mysite.com/wiki/pagename is far preferable to www.mysite.com/wiki/index.php/pagename which in turn is preferable to www.mysite.com/wiki/index.php?title=pagename
4: avoid capitals or at the very least provide an alias with them downcased.
5: minimise the ammount of different symbols in the url, especially try to avoid symbols which require shift or are unfamiliar to non-geeks (the underscore is both!)
6: if you must use meaningless identifiers (it is pretty hard to avoid them with things like forums and bugtrackers) make them base 10 numbers. Going to base, 16, 32 or 64 will save you a little length but will make your url much harder for most people to remember.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
So, with my free texting plan I can blackmail US telco customers. Sweet. Pay me $100 now or I will send you 1000 text messages.
The parent is not Informative, rev in this case is correct since the resource linked is a NOT the canonical page but a short-url version of the canonical page you are currently on, so the relationship is:
page A with long URL <--is the canonical url of--- page B with short URL
and NOT
page A with long URL ---is another address for the canonical url--> page B with short URL
Page A is the canonical, the long URL page is the authoritative destination, page B is just a shortcut, and not the other way around, so when in page A, if your software are looking for alternate address of that canonical page with shorter urls your software should look for reverse links containing "canonical" as the value. Links for pages that have the current page as the canonical are the ones with rev, not rel.
See http://www.w3.org/TR/html401/struct/links.html#h-12.3.1 to understand.
I admit it is a little confusing, maybe they should be using rel="alternate mirror", rel="alternate short-url" or simply rel="alternate" instead, to indicate that the link points to an alternate version of the current page. But saying that the link is of a page that points reversely to the current page that is the canonical is not wrong
.. sending multipart SMS multiplies the failure rate for any given message.
I'd have thought it would actually reduce it. The multipart messages surely have some sort of flag to indicate there's another part. This would mean that the upstream transponder could be signalled to resend the message if the additional part is not received. You'd effectively have n chances (for an n-part message) to indicate a message was sent. There would be some increased chance of total loss but greater chance of receipt - the message being resent until it was complete.
But I don't really know that much about SMS to know if it was engineered or just thrown together.
We recently launched a new website that provides a URL shortening service for "multiple" websites: http://www.viewista.com/ Viewista creates a short URL for âoemultipleâ websites. Plus, you can view the multiple sites all at once. We think it can be a real time-saver. You can also post comments on the sites and share with your friends, making it a social URL sharing service. Viewista can be particularly useful on Twitter because a user can create a short URL for multiple sites on a topic without having to use multiple tweets.