licentious radio

Monday, March 11, 2002
[10:58:59 AM]

It's hard to make fun of the rogue-government that seized power.

You do your best to joke about Little George being dumb, but then he goes and tries to get Stevie Wonder's attention by waving. Little George: one of the things about blind people is that they can't see.

And then you mock the military, but they've decided to aim nukes at anybody they think might mess with them.

"Any guff from one of these countries, and they're radioactive toast," said Rice.

That's not funny.

Even the whole pretzel thing is too unlikely to be funny. Many people have eaten a pretzel without losing consciousness. It's a lot more likely that Little George was falling-down drunk. Maybe it wasn't even very much alcohol, but it reacted badly with his meds. We'll never know, and it isn't funny, but it's about a thousand times more plausible than the pretzel story.

[10:45:56 AM]
We don't like linkrot. John S. Rhodes suggests fighting linkrot [webword.com] with web services: when a url changes, the server tells any computer that asked for the update. That's nice, and will add value.

But the right thing is to set up your web server so the urls don't change. Put your files someplace, and leave them there, maybe.

Second, make the url part of what you track in the database. If you change the url for a page in the database, automatically generate the redirection page. But better yet, just keep the same url. This works because urls are abstract, not an exact mapping to subdirectories and files.

For example, say your old publishing system used whacky urls, but your new publishing system uses a different scheme. Just map the old whacky urls to the matching page in the new scheme. It's not hard. You know the old url, and you know the new url. The mapping functionality is in your web server.

And for that matter, if you don't like whacky urls, you could come up with your own scheme, and map the urls you want your customers to see to whatever your publishing system generates and/or responds to.

The fundamental concept here is that the server *decides* which resource to deliver. Deciding which existing page to deliver is very cheap in terms of processing power -- compared to generating pages on the fly, for example.

I have extensive notes on URLs at my other website.

Proposed hack: if you move a page -- to a different domain, for example -- put the old url in the new page (this page formerly at: oldurl). Users could search Google for the old url, and find your new page.