diff options
Diffstat (limited to '.html/cool-urls-can-change.html')
| -rw-r--r-- | .html/cool-urls-can-change.html | 142 |
1 files changed, 142 insertions, 0 deletions
diff --git a/.html/cool-urls-can-change.html b/.html/cool-urls-can-change.html new file mode 100644 index 0000000..f61f8e4 --- /dev/null +++ b/.html/cool-urls-can-change.html @@ -0,0 +1,142 @@ +<!DOCTYPE html> +<html> +<head> + <title> + The Codex » + Cool URLs Do Change (Sometimes) + </title> + + <link + rel='stylesheet' + type='text/css' + href='http://fonts.googleapis.com/css?family=Buenard:400,700&subset=latin,latin-ext'> + <link + rel="stylesheet" + type="text/css" + href="media/css/reset.css"> + <link + rel="stylesheet" + type="text/css" + href="media/css/grimoire.css"> +</head> +<body> + +<div id="shell"> + + <ol id="breadcrumbs"> + + <li class="crumb-0 not-last"> + + <a href="./">index</a> + + </li> + + <li class="crumb-1 last"> + + cool-urls-can-change + + </li> + + </ol> + + + + <div id="article"> + <h1 id="cool-urls-do-change-sometimes">Cool URLs Do Change (Sometimes)</h1> +<p>Required reading: <a href="http://www.w3.org/Provider/Style/URI.html">Cool URLs don't +change</a>.</p> +<p>When I wrote <a href="http://codex.grimoire.ca/2008/09/24/nobody-cares-about-your-build/">Nobody Cares About Your +Build</a>, I +set up a dedicated publishing platform - Wordpress, as it happens - to host +it, and as part of that process I put some real thought into the choice of +“permalink” schemes to use. I opted to use a “dated” scheme, baking the +publication date of each article into its name - into its URL - for all +eternity. I'm a big believer in the idea that a URL should be a long-term name +for the appropriate bit of data or content, and every part of a dated scheme +“made sense” at the time.</p> +<p>This turned out to be a mistake.</p> +<p>The web is not, much, like print media. Something published may be amended; +you don't even have to publish errata or a correction, since you can correct +the original mistake “seamlessly.” This has its good and its +<a href="http://en.wikipedia.org/wiki/Memory_hole">bad</a> parts, but with judicious use +and <a href="https://github.com/ojacobson/grimoiredotca">a public history</a>, amendment +is more of a win than a loss. However, this plays havoc with the idea of a +“publication” date, even for data that takes the form of an article: is the +publication date the date it was first made public, the date of its most +recent edit, or some other date?</p> +<p>Because the name - the URL - of an article was set when I first published it, +the date in the name had to be its initial publication date. <em>This has +actually stopped me from making useful amendments to old articles</em> because the +effort of writing a full, free-standing followup article is more than I'm +willing to commit to. Had I left the date out of the URLs, I'd feel more free +to judiciously amend articles in place and include, in the content, a short +amendment summary.</p> +<p>The W3C's informal suggestions on the subject state that “After the creation +date, putting any information in the name is asking for trouble one way or +another.” I'm starting to believe that this doesn't go far enough: <em>every</em> +part of a URL must have some semantic justification for being there, dates +included:</p> +<ol> +<li> +<p><em>Each part must be meaningful</em>. While + <code>http://example.com/WW91IGp1c3QgbG9zdCB0aGUgZ2FtZQ==</code> is fairly easy to + render stable, the meaningless blob renders the name immemorable.</p> +</li> +<li> +<p><em>Each part must be stable</em>. This is where I screwed up worst: I did not + anticipate that the “date” of an article could be a fluid thing. It's + tempting to privilege the first date, and it's not an unreasonable + solution, but it didn't fit how I wanted to address the contents of + articles.</p> +</li> +</ol> +<p>Running a web server gives you one namespace to play with. Use it wisely.</p> +<h2 id="ok-but-ive-already-got-these-urls">Ok, But I've Already Got These URLs</h2> +<p>Thankfully, there's a way out - for <em>some</em> URLs. URLs inherently name +resources <em>accessed using some protocol</em>, and some protocols provide support +for resources that are, themselves, references to other URLs. HTTP is a good +example, providing a fairly rich set of responses that all, fundamentally, +tell a client to check a second URL for the content relevent to a given URL. +In protocols like this, you can easily replace the content of a URL with a +reference to its new, “better” URL rather than abandoning it entirely.</p> +<p>Names can evolve organically as the humans that issue them grow a better +understanding of the problem, and don't always have to be locked in stone from +the moment they're first used.</p> + </div> + + + +<div id="comments"> +<div id="disqus_thread"></div> +<script type="text/javascript"> + /* * * CONFIGURATION VARIABLES: EDIT BEFORE PASTING INTO YOUR WEBPAGE * * */ + var disqus_shortname = 'grimoire'; // required: replace example with your forum shortname + + /* * * DON'T EDIT BELOW THIS LINE * * */ + (function() { + var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true; + dsq.src = 'http://' + disqus_shortname + '.disqus.com/embed.js'; + (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq); + })(); +</script> +<noscript>Please enable JavaScript to view the <a href="http://disqus.com/?ref_noscript">comments powered by Disqus.</a></noscript> +<a href="http://disqus.com" class="dsq-brlink">comments powered by <span class="logo-disqus">Disqus</span></a> +</div> + + + + <div id="footer"> + <p> + + The Codex — + + Powered by <a href="http://markdoc.org/">Markdoc</a>. + +<a href="https://bitbucket.org/ojacobson/grimoire.ca/src/master/wiki/cool-urls-can-change.md">See this page on Bitbucket</a> (<a href="https://bitbucket.org/ojacobson/grimoire.ca/history-node/master/wiki/cool-urls-can-change.md">history</a>). + + </p> + </div> + +</div> +</body> +</html>
\ No newline at end of file |