ntang (ntang) wrote,

Stupid Human Tricks: PURLs [g]

I was reading Netcraft's newsfeed today, and came across this article:

Ok, URNs, fair enough. I decided to look at the first solution, the PURL, or Persistent URL. It sounds like a potentially good concept, right? A URL that doesn't change, that follows the content, so you never have to worry about 404's and broken links. Sweet!

Except... well, first off, here's their 30-second description:
A PURL is a Persistent Uniform Resource Locator. Functionally, a PURL is a URL. However, instead of pointing directly to the location of an Internet resource, a PURL points to an intermediate resolution service. The PURL resolution service associates the PURL with the actual URL and returns that URL to the client. The client can then complete the URL transaction in the normal fashion. In Web parlance, this is a standard HTTP redirect.

The OCLC PURL Service has been strongly influenced by the active participation of OCLC's Office of Research in the Internet Engineering Task Force Uniform Resource Identifier working groups. There is nothing incompatible between PURLs and the ongoing URN (Uniform Resource Name) work. PURLs satisfy many of the requirements of URNs using currently deployed technologies and can be transitioned smoothly into a URN architecture once it is deployed.

Ok, does anyone see the problem with this whole concept? URLs are ALREADY VIRTUAL! While not everyone uses them in that fashion, this does nothing new, and wastes a whole lot of time doing it. URLs can already redirect to other URLs, the reason why their brilliant idea doesn't break anything is because IT DOESN'T CHANGE ANYTHING. All they seem to have done is made a simple web interface (I'm assuming, I didn't actually try to use it) for mod_rewrite and they're trying to play this off as some brilliant idea? Oy vey.

There comes a point at which extra layers of abstraction just make life more complex. DNS is already employs a layer of abstraction over ip addresses, which are a layer of abstraction over MAC addresses, which are a layer over physical interfaces. And, of course, URLs themselves are a layer of abstraction over files (and since the host part of it uses DNS, by extension, over ip addresses as well, or perhaps over DNS). ENOUGH ALREADY. What's really ridiculous is that PURLs don't abstract a new layer; they re-abstract an existing layer of abstraction. It'd make my head hurt if my head didn't already hurt. I can't believe an entire team of academics wasted their time coming up with this - and that this is the best they could do. What happens when you want to move a URL? You update the PURL. By hand. This helps... how? And it assumes that you'll get your PURL hierarchy right; what happens when you realize that you laid out your PURLs in a stupid fashion?

Oh, I know, I know! PPURLs! People, if we accept PURLs today, 30 years from now someone will be proposing the PPPPPPPPPPURL, and they'll be hailed as a genius. I can't accept that world, and neither should you. STOP THE MADNESS.

(That's it. I was originally thinking of doing a longer rant but I'm too tired. Needless to say, PURLs == teh suck.)
  • Post a new comment


    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

    Your IP address will be recorded