What is it with boost and tinyurl?
It seems to me that boost developers are particularly enamored with tinyurl. While I agree that there are cases when tinyurl is a good thing, I can't but think that in many cases where it's used on boost lists it does more harm than good. Tinyurl (and similar services) discard valuable information from the URL. I often use information in the URL itself to judge whether the topic being discussed is of interest to me. Example: Useless: <http://tinyurl.com/4ghk7> Useful: <http://boost.sourceforge.net/regression-logs/cs-win32_metacomm/developer/pro... _options.html> ("Don't need to click if you are not interested in win32 regression of program options.") Useless: <http://tinyurl.com/yrotd> Useful: <http://lists.boost.org/MailArchives/boost/msg61026.php> ("Herein I refer to a previous thread on this mailing list.") Both of those examples were recently posted to the mailing list, and in both cases there was not enough context in the surrounding text for me to determine what the URL was about (without having to read several messages in the thread). I could name at least two other reasons for why tinyurl is not a great idea: first, it means that tinyurl.com can track my web access; second, if tinyurl is down, I am screwed. Neither of those two is as important to me as the reason I outlined above, though. Finally, URL line wrapping is a well-understood problem, with a recommended practice (namely, enclosing URLs in text inside <>, as I did above) codified in the current URL RFC. Every email and usenet client I am aware of does the right thing with line-wrapped URLs in angle brackets. If someone wants to convince me that tinyurl provides a valuable service to the community, I am listening. If not, I kindly request that those people who are in the habit of using tinyurl reconsider it. Thanks, meeroh -- If this message helped you, consider buying an item from my wish list: <http://web.meeroh.org/wishlist>
Miro Jurisic wrote:
<http://boost.sourceforge.net/regression-logs/cs-win32_metacomm/developer/pro... _options.html>
And right there you can see why we use tinyurl ;-)
Finally, URL line wrapping is a well-understood problem, with a recommended practice (namely, enclosing URLs in text inside <>, as I did above) codified in the current URL RFC. Every email and usenet client I am aware of does the right thing with line-wrapped URLs in angle brackets.
Obviously not true for your own client: MT-NewsWatcher/3.4 (PPC Mac OS X). Or perhaps it's my client, Mozilla Thunderbird, not reading it correctly. But certainly two common programs. PS. I really don't care either way about the argument... Just found the resulting irony entertaining :-] -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq
In article <40FE1975.3090809@redshift-software.com>, Rene Rivera <grafik.list@redshift-software.com> wrote:
Finally, URL line wrapping is a well-understood problem, with a recommended practice (namely, enclosing URLs in text inside <>, as I did above) codified in the current URL RFC. Every email and usenet client I am aware of does the right thing with line-wrapped URLs in angle brackets.
Obviously not true for your own client: MT-NewsWatcher/3.4 (PPC Mac OS X). Or perhaps it's my client, Mozilla Thunderbird, not reading it correctly. But certainly two common programs.
My client DTRT, but from reports throughout this thread, it sounds like Mozilla is broken in this regard, which is very sad. For those of you interested in getting this class of bugs fixed in your newsreaders and mail clients, please file bugs referring to appendix of RFC 1738, which states: " [...] it is convenient to have a separate syntactic wrapper that delimits the URL and separates it from the rest of the text, and in particular from punctuation marks that might be mistaken for part of the URL. For this purpose, is recommended that angle brackets ("<" and ">"), along with the prefix "URL:", be used to delimit the boundaries of the URL. This wrapper does not form part of the URL and should not be used in contexts in which delimiters are already specified. [...] In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may need to be added to break long URLs across lines. The whitespace should be ignored when extracting the URL. " Given the feedback here, I am less adamantly against tinyurl, although I would still prefer to avoid it (but that's easy for me, because my client works :-) ) meeroh -- If this message helped you, consider buying an item from my wish list: <http://web.meeroh.org/wishlist>
Miro Jurisic wrote:
My client DTRT, but from reports throughout this thread, it sounds like Mozilla is broken in this regard, which is very sad.
For those of you interested in getting this class of bugs fixed in your newsreaders and mail clients, please file bugs referring to appendix of RFC 1738, which states:
"
[...] it is convenient to have a separate syntactic wrapper that delimits the URL and separates it from the rest of the text, and in particular from punctuation marks that might be mistaken for part of the URL. For this purpose, is recommended that angle brackets ("<" and ">"), along with the prefix "URL:", be used to delimit the boundaries of the URL. This wrapper does not form part of the URL and should not be used in contexts in which delimiters are already specified.
[...] "
I hope you realize that your URLs did not include the "URL:" prefix recommended above... perhaps more clients could cope if it did (though I have my doubts). -- Jason McCarty <bclg@iup.edu>
In article <20040721223428.GA384@iup.edu>, Jason McCarty <bclg@iup.edu> wrote:
[...] it is convenient to have a separate syntactic wrapper that delimits the URL and separates it from the rest of the text, and in particular from punctuation marks that might be mistaken for part of the URL. For this purpose, is recommended that angle brackets ("<" and ">"), along with the prefix "URL:", be used to delimit the boundaries of the URL. This wrapper does not form part of the URL and should not be used in contexts in which delimiters are already specified.
[...] "
I hope you realize that your URLs did not include the "URL:" prefix recommended above... perhaps more clients could cope if it did (though I have my doubts).
My quote from the RFC was not intended to be a complete treatment of the topic, though I agree that it could mislead one into thinking that <> and URL: were both recommended in the specific context we are discussing here. However, this is getting off-topic for boost, so I will leave it up to you to read the remainder of the appendix I referred to and follow up in personal email if you have further questions. meeroh -- If this message helped you, consider buying an item from my wish list: <http://web.meeroh.org/wishlist>
On 7/21/04 3:46 PM, "Miro Jurisic" <macdev@meeroh.org> wrote:
In article <40FE1975.3090809@redshift-software.com>, Rene Rivera <grafik.list@redshift-software.com> wrote:
Finally, URL line wrapping is a well-understood problem, with a recommended practice (namely, enclosing URLs in text inside <>, as I did above) codified in the current URL RFC. Every email and usenet client I am aware of does the right thing with line-wrapped URLs in angle brackets.
Obviously not true for your own client: MT-NewsWatcher/3.4 (PPC Mac OS X). Or perhaps it's my client, Mozilla Thunderbird, not reading it correctly. But certainly two common programs.
My client DTRT, but from reports throughout this thread, it sounds like Mozilla is broken in this regard, which is very sad.
From the readings here, I think more clients are broken than handle this correctly. (My client, MS Entourage X, also got the original poster's URL wrong.)
For those of you interested in getting this class of bugs fixed in your newsreaders and mail clients, please file bugs referring to appendix of RFC 1738, which states:
"
[...] it is convenient to have a separate syntactic wrapper that delimits the URL and separates it from the rest of the text, and in particular from punctuation marks that might be mistaken for part of the URL. For this purpose, is recommended that angle brackets ("<" and ">"), along with the prefix "URL:", be used to delimit the boundaries of the URL. This wrapper does not form part of the URL and should not be used in contexts in which delimiters are already specified.
I think the original poster forgot the "URL:" part.
[...]
In some cases, extra whitespace (spaces, linebreaks, tabs, etc.) may need to be added to break long URLs across lines. The whitespace should be ignored when extracting the URL.
"
The problem isn't the white space. The real problem is that the character that ends an URL bracketing is the same as the usual line quoting character (">"). Unless your client is _really_ smart, multi-line URLs get cut off at the beginning of their second line.
Given the feedback here, I am less adamantly against tinyurl, although I would still prefer to avoid it (but that's easy for me, because my client works :-) )
-- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Miro Jurisic wrote:
Useless:
Useful:
<http://boost.sourceforge.net/regression-logs/cs-win32_metacomm/developer/p rogram _options.html>
("Don't need to click if you are not interested in win32 regression of program options.")
The message you refer too has [program_options] in the subject, so I think that's enough of context...
Finally, URL line wrapping is a well-understood problem, with a recommended practice (namely, enclosing URLs in text inside <>, as I did above) codified in the current URL RFC. Every email and usenet client I am aware of does the right thing with line-wrapped URLs in angle brackets.
Neither KMail 1.6 nor Mozilla 1.7 could open the above long URL :-( - Volodya
If someone wants to convince me that tinyurl provides a valuable service to the community, I am listening. If not, I kindly request that those people who are in the habit of using tinyurl reconsider it.
I second this. Once per week or so (on some occasions several times in a week) I have been unable to reach webpages referred to because I could not contact tinyurl.com. This is frustrating; I know the page is somewhere on boost.org, and I know I can reach the website, I just can't reach the middleman that's hiding the real URL from me. If the URL is very long and you would prefer not to clutter your message with it, an alternative is to make a footnote like this [1]. /Mattias [1] <http://www.google.com/>
Miro Jurisic writes:
It seems to me that boost developers are particularly enamored with tinyurl. While I agree that there are cases when tinyurl is a good thing, I can't but think that in many cases where it's used on boost lists it does more harm than good.
FWIW, I myself never experienced the inconveniences you describe below.
Tinyurl (and similar services) discard valuable information from the URL. I often use information in the URL itself to judge whether the topic being discussed is of interest to me.
Example:
Useless:
Useful:
<http://boost.sourceforge.net/regression-logs/cs-win32_metacomm/developer/pro... _options.html>
("Don't need to click if you are not interested in win32 regression of program options.")
Unless you point to the particular message in which the link appeared and at least some of us agree that the context didn't convey there the link is going to take you (in terms of the page content), I'm for one inclined to see this and the following examples as biased.
Useless:
Useful:
<http://lists.boost.org/MailArchives/boost/msg61026.php>
("Herein I refer to a previous thread on this mailing list.")
Both of those examples were recently posted to the mailing list, and in both cases there was not enough context in the surrounding text for me to determine what the URL was about (without having to read several messages in the thread).
I could name at least two other reasons for why tinyurl is not a great idea: first, it means that tinyurl.com can track my web access; second, if tinyurl is down, I am screwed.
The latter is the only real problem with it, IMO.
Neither of those two is as important to me as the reason I outlined above, though.
Finally, URL line wrapping is a well-understood problem, with a recommended practice (namely, enclosing URLs in text inside <>, as I did above) codified in the current URL RFC. Every email and usenet client I am aware of does the right thing with line-wrapped URLs in angle brackets.
There are plenty that don't. -- Aleksey Gurtovoy MetaCommunications Engineering
Miro Jurisic <macdev@meeroh.org> writes:
<http://boost.sourceforge.net/regression-logs/cs-win32_metacomm/developer/pro... _options.html>
<snip> Points taken.
Finally, URL line wrapping is a well-understood problem, with a recommended practice (namely, enclosing URLs in text inside <>, as I did above) codified in the current URL RFC. Every email and usenet client I am aware of does the right thing with line-wrapped URLs in angle brackets.
Not mine. Or maybe it's your mailer. Either way, Gnus is showing it wrapped and only the first line of the link is active. Those Gnus guys are comparatively pretty aware of standards, too. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
Miro Jurisic <macdev@meeroh.org> writes:
Finally, URL line wrapping is a well-understood problem, with a recommended practice (namely, enclosing URLs in text inside <>, as I did above) codified in the current URL RFC. Every email and usenet client I am aware of does the right thing with line-wrapped URLs in angle brackets.
Not mine. Or maybe it's your mailer. Either way, Gnus is showing it wrapped and only the first line of the link is active. Those Gnus guys are comparatively pretty aware of standards, too.
Interestingly, the gnus function to remove newlines from URLs (gnus-article-unsplit-urls), which I normally find does a great job, doesn't work on the split URL in the original post. Anthony -- Anthony Williams Senior Software Engineer, Beran Instruments Ltd.
Miro Jurisic <macdev@meeroh.org> wrote:
It seems to me that boost developers are particularly enamored with tinyurl. While I agree that there are cases when tinyurl is a good thing, I can't but think that in many cases where it's used on boost lists it does more harm than good.
Tinyurl (and similar services) discard valuable information from the URL. I often use information in the URL itself to judge whether the topic being discussed is of interest to me.
I'd like to add that, of the half-dozen free/open software lists I read, boost is the only list that uses tinyurl's. Making boost more or less dependent on tinyurl seems unnecessary. In addition, someone who is not mark may post a url like http://foo.com/~mark/new_algorithm.pdf Later mark (not the original poster) moves their site to mark.com, so the site moves to http://mark.com/new_algorithm.pdf With tinyurl's, it is much harder or impossible to find the new page. Cheers, Walter Landry wlandry@ucsd.edu
From: Walter Landry <wlandry@ucsd.edu>
Miro Jurisic <macdev@meeroh.org> wrote:
It seems to me that boost developers are particularly enamored with tinyurl. While I agree that there are cases when tinyurl is a good thing, I can't but think that in many cases where it's used on boost lists it does more harm than good.
Tinyurl (and similar services) discard valuable information from the URL. I often use information in the URL itself to judge whether the topic being discussed is of interest to me.
They also solve real problems.
I'd like to add that, of the half-dozen free/open software lists I read, boost is the only list that uses tinyurl's. Making boost more or less dependent on tinyurl seems unnecessary. In addition, someone
As has been illustrated already in this thread, the use of TinyURL is not unnecessary.
who is not mark may post a url like
http://foo.com/~mark/new_algorithm.pdf
Later mark (not the original poster) moves their site to mark.com, so the site moves to
http://mark.com/new_algorithm.pdf
With tinyurl's, it is much harder or impossible to find the new page.
For this and the OP's reasons, may I suggest that all links be done both ways? The long one could be put in a footnote, as suggested previously, but with both URLs, you get the best of both worlds. (The long URL may well get munged, but the information it conveys remains and the TinyURL should be unaffected by quoting.) -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Rob Stewart <stewart@sig.com> writes:
From: Walter Landry <wlandry@ucsd.edu>
Miro Jurisic <macdev@meeroh.org> wrote:
It seems to me that boost developers are particularly enamored with tinyurl. While I agree that there are cases when tinyurl is a good thing, I can't but think that in many cases where it's used on boost lists it does more harm than good.
Tinyurl (and similar services) discard valuable information from the URL. I often use information in the URL itself to judge whether the topic being discussed is of interest to me.
They also solve real problems.
I'd like to add that, of the half-dozen free/open software lists I read, boost is the only list that uses tinyurl's. Making boost more or less dependent on tinyurl seems unnecessary. In addition, someone
As has been illustrated already in this thread, the use of TinyURL is not unnecessary.
who is not mark may post a url like
http://foo.com/~mark/new_algorithm.pdf
Later mark (not the original poster) moves their site to mark.com, so the site moves to
http://mark.com/new_algorithm.pdf
With tinyurl's, it is much harder or impossible to find the new page.
It looks hard or impossible to me even without tinyurls. How do tinyurls hurt this situation? Are you really likely to find the new url by probing likely new urls based on the old one?
For this and the OP's reasons, may I suggest that all links be done both ways?
Too much trouble. I certainly wouldn't want to set that policy; it would just discourage posting links. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
David Abrahams wrote:
Rob Stewart writes:
For this and the OP's reasons, may I suggest that all links be done both ways?
Too much trouble. I certainly wouldn't want to set that policy; it would just discourage posting links.
Too much trouble? An extra Ctrl+V is too much trouble for someone who doesn't mind opening tinyurl.com, pasting the link there, copying the result, and pasting it back?
"Peter Dimov" <pdimov@mmltd.net> writes:
David Abrahams wrote:
Rob Stewart writes:
For this and the OP's reasons, may I suggest that all links be done both ways?
Too much trouble. I certainly wouldn't want to set that policy; it would just discourage posting links.
Too much trouble? An extra Ctrl+V is too much trouble for someone who doesn't mind opening tinyurl.com, pasting the link there, copying the result, and pasting it back?
TinyURL is already a pain. Anyone's welcome to do it but I doubt I'll go to the trouble. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
From: David Abrahams <dave@boost-consulting.com>
Rob Stewart <stewart@sig.com> writes:
From: Walter Landry <wlandry@ucsd.edu>
I'd like to add that, of the half-dozen free/open software lists I read, boost is the only list that uses tinyurl's. Making boost more or less dependent on tinyurl seems unnecessary. In addition, someone who is not mark may post a url like
http://foo.com/~mark/new_algorithm.pdf
Later mark (not the original poster) moves their site to mark.com, so the site moves to
http://mark.com/new_algorithm.pdf
With tinyurl's, it is much harder or impossible to find the new page.
It looks hard or impossible to me even without tinyurls. How do tinyurls hurt this situation? Are you really likely to find the new url by probing likely new urls based on the old one?
If you were aware that foo.com/~mark became mark.com, you could make the translation having the other information in the original URL. Using the TinyURL, the information is lost. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Miro Jurisic wrote:
<http://boost.sourceforge.net/regression-logs/cs-win32_metacomm/developer/pro... _options.html>
[...]
Finally, URL line wrapping is a well-understood problem, with a recommended practice (namely, enclosing URLs in text inside <>, as I did above) codified in the current URL RFC. Every email and usenet client I am aware of does the right thing with line-wrapped URLs in angle brackets.
FWIW, the above long URL is apparently not clickable here (Mozilla 1.6) due to wrapping. Quoting it in a message (as in this one) will likely reduce the number of clients which detect the URL. I tend to ignore non-clickable URLs. I guess other people ignore them, too. Regards, m
On 7/21/04 7:32 PM, "Darren Cook" <darren@dcook.org> wrote:
Tinyurl (and similar services) discard valuable information from the URL. I often use information in the URL itself to judge whether the topic being discussed is of interest to me.
I agree. I'd rather see long URLs so I have an idea of where it will take me.
I hate the lack of context too. Also, the Tiny-URL may hide an unknown number of web-commission re-directs. (Doesn't one of these services proclaim that reason as why you can't look up their short-hand URLs in advance?) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Daryle Walker <darylew@hotmail.com> writes:
On 7/21/04 7:32 PM, "Darren Cook" <darren@dcook.org> wrote:
Tinyurl (and similar services) discard valuable information from the URL. I often use information in the URL itself to judge whether the topic being discussed is of interest to me.
I agree. I'd rather see long URLs so I have an idea of where it will take me.
I hate the lack of context too. Also, the Tiny-URL may hide an unknown number of web-commission re-directs. (Doesn't one of these services proclaim that reason as why you can't look up their short-hand URLs in advance?)
You can always perform the lookup with an HTTP client that merely prints, but does not follow, redirect responses. -- Jeremy Maitin-Shepard
Miro Jurisic wrote:
Tinyurl (and similar services) discard valuable information from the URL. I often use information in the URL itself to judge whether the topic being discussed is of interest to me.
To add another example of existing practice, in some forums where hypertext links are used, it is considered impolite to post a clickable URL without at least mentioning in plaintext the domain name that it refers to. I don't know how much information a domain name adds, but I think a lot of people, myself included, don't like clicking on blind links. Also, how long do tinyurls last? A year from now, when someone is searching the archives, will they still be able to follow a tinyurl? Three years from now? Aaron W. LaFramboise
Aaron W. LaFramboise writes:
Miro Jurisic wrote:
Tinyurl (and similar services) discard valuable information from the URL. I often use information in the URL itself to judge whether the topic being discussed is of interest to me.
To add another example of existing practice, in some forums where hypertext links are used, it is considered impolite to post a clickable URL without at least mentioning in plaintext the domain name that it refers to.
Sounds like a drastic practice on empty grounds. Do you *really* care whether the link takes you to www.boost.org/regression-logs/something or www.meta-comm.com/engineering/something? Why?
I don't know how much information a domain name adds, but I think a lot of people, myself included, don't like clicking on blind links.
Can you cite a single example of the Boost posting that contains a link that you didn't follow because you were afraid/didn't know where it'd take you in terms of the domain?
Also, how long do tinyurls last?
They never expire. Of course there is always a chance that the service will die and the domain will be acquired by somebody with entirely different goals, but then there is very little in this world that is truly permanent.
A year from now, when someone is searching the archives, will they still be able to follow a tinyurl? Three years from now?
The *original* URLs, especially the ones we are using tinyurls for, usually don't last/become uninteresting in a fraction of that period of time. -- Aleksey Gurtovoy MetaCommunications Engineering
Aleksey Gurtovoy wrote:
Aaron W. LaFramboise writes:
Miro Jurisic wrote:
Tinyurl (and similar services) discard valuable information from the URL. I often use information in the URL itself to judge whether the topic being discussed is of interest to me.
To add another example of existing practice, in some forums where hypertext links are used, it is considered impolite to post a clickable URL without at least mentioning in plaintext the domain name that it refers to.
Sounds like a drastic practice on empty grounds. Do you *really* care whether the link takes you to www.boost.org/regression-logs/something or www.meta-comm.com/engineering/something? Why?
I'm not sure if its drastic or not, but I do appreciate it. (A degenerate counterexample is when friends used to send links to me on AIM that said 'click here' and there was no way to tell what it was until I did.) Also, for these two URLs, I can't figure out exactly what tinyurl adds. Neither has been broken by wrapping, and even if they had, I can trivially fix it in less time than it takes to form a tinyurl in the first place.
I don't know how much information a domain name adds, but I think a lot of people, myself included, don't like clicking on blind links.
Can you cite a single example of the Boost posting that contains a link that you didn't follow because you were afraid/didn't know where it'd take you in terms of the domain?
No, but I do feel generally that the more information I have before I click, the better. As the OP pointed out, a URL can (and perhaps should) say a lot about the material it refers to, which makes it a lot easier to judge whether or not its something I'm interested in. (This may not seem important, but for someone like me who browses hundreds of emails a day, URLs and similar are highlights that my eyes jump to when attempting to quickly glean information from posts.)
Also, how long do tinyurls last?
They never expire. Of course there is always a chance that the service will die and the domain will be acquired by somebody with entirely different goals, but then there is very little in this world that is truly permanent.
A year from now, when someone is searching the archives, will they still be able to follow a tinyurl? Three years from now?
The *original* URLs, especially the ones we are using tinyurls for, usually don't last/become uninteresting in a fraction of that period of time.
This point is reasonable. However, there are quite a few opposing cases where information in an email lives for a long time. Countless times I find myself retreiving a valuable link from an archived email perhaps a decade old. Often the URL is dead, but at the very least, I have an organization name, a username, or at least a filename, that gives me a fighting chance to find the information with a search engine. If tinyurl dies, all of this information is gone forever, and quite likely much would not be retreivable. My interested two cents, Aaron W. LaFramboise
They never expire. Of course there is always a chance that the service will die and the domain will be acquired by somebody with entirely different goals, but then there is very little in this world that is truly permanent.
A year from now, when someone is searching the archives, will they still be able to follow a tinyurl? Three years from now?
The *original* URLs, especially the ones we are using tinyurls for, usually don't last/become uninteresting in a fraction of that period of time.
There is always the internet archive (http://www.archive.org) to help with this. But this particular thread of the discussion is a moot point anyway, since if you can go through the trouble to investigate where a lost page went, I'm sure you can go through the trouble to figure out which URL tinyurl.com is redirecting to (even if you get a 404, you should be able to see the real URL in the URL field of your browser, or telnet to the server and catch the redirect if you have to). In any case, both sides have had too many good arguments to be able to come to any decisive conclusions, I think. But at least, I hope fellow boosters have been nudged to exercise some moderation in the use of tinyurls. No reason for obfuscation if the URL is already short enough (and in my own very personal opinion, 60 characters or less should be short enough). /Mattias
participants (16)
-
Aaron W. LaFramboise -
Aleksey Gurtovoy -
Anthony Williams -
Darren Cook -
Daryle Walker -
David Abrahams -
Jason McCarty -
Jeremy Maitin-Shepard -
Martin Wille -
Mattias Flodin -
Miro Jurisic -
Peter Dimov -
Rene Rivera -
Rob Stewart -
Vladimir Prus -
Walter Landry