Boost logo

Boost :

From: Miro Jurisic (macdev_at_[hidden])
Date: 2004-07-21 01:47:06


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/program
_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>

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk