I hate having to use <code><pre> rather than <code style=’white-space: pre’>, but aggregators and feed readers ignore external CSS, and Planet strips CSS entirely from the embedded HTML. Blah. Here’s to XML in 2010. Maybe we’ll use it to its advantage then.
IPv6
I just got pTRTd and TOTd working on the local network. If you use the right nameserver, it’ll direct requests for all names to be translated to IPv6 addresses by TOTd. The names it returns are (by configuration) magically happening to be the ones that pTRTd will forward to the IPv4 host, meaning that a machine speaking only IPv6 can talk to the IPv4 internet:
`
aredridel@betelgeuse:~$ telnet google.com 80 Trying 1000::d8ef:3963... Connected to google.com. Escape character is '^]'. GET / HTTP/1.1 Host: google.com`HTTP/1.1 302 Found Location: http://www.google.com/ Set-Cookie: PREF=ID=5568f1724a0d5c4b:TM=1108068407:LM=1108068407:S=6Z7R1-PKbx73Xmu6; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.com Content-Type: text/html Server: GWS/2.1 Content-Length: 152 Date: Thu, 10 Feb 2005 20:46:47 GMT
<HTML><HEAD><TITLE>302 Moved</TITLE></HEAD><BODY> <H1>302 Moved</H1> The document has moved <A HREF="http://www.google.com/">here</A>. </BODY></HTML>
Connection closed by foreign host.
Pretty cool, eh? Yes, on my network, 1000::d8ef:3963 is Google. It’s not a legal address, and my first attempt to use the site-local fec0:: address space failed: Linux does some weird shit to addresses like that. At least since IPv6 has so much address space, you don’t need to use site-local addresses except as the Right Thing for local translators and things like that. Oh, well. I just yoinked 1000::/64 since all legal IPv6 addresses currently live in 2000::/3 or 3ffe::/16.
376
I just said goodbye to Meli, my cousin. She’s headed back to Aspen to work the rest of the winter, then back to Buenos Aires. She says I should come to Argentina. Maybe after I pay off the business…
375
I should be in bed, but instead I hacked on the Wiki renderer, adding something I’ve wanted to do for a while — add XHTML2-inspired links. Any normal markup can now have <url> appended to it, and it will turn the previous thing into a link. I think it’s delightfully clean, just as the href attribute working on nearly any element in XHTML2 is elegant.
373
It’s amazing how little changes between the time you go to bed and the time you get up when you go to bed at 3 and get up at 8.
I woke up to a Guster track that Robyn sent me. It’s on my top ten favorite songs list, for sure. When nobody’s looking, I dance to it.
My cat is a pain in the ass. He got his dinner last night, but I think he’s being preemptive about making sure he gets fed, and we have no food for him until I go to the pet food store. A few minutes ago, he jumped up and hung on my back. Now he’s in my lap, kneading my thighs with more claw than is really neccesary. All the while, he acts so cute you could hardly tell him to get lost.
372
http://www.livejournal.com/community/transnews/481667.html: My day just got much better,
371
I completed 1/4 of what’s needed to get rid of LDAP in my infrastructure for The Internet Company, and replace it with PostgreSQL.
Complete: Replication with Slony-1
Remaining: Convert DNS and users to SQL. Enable nss_pgsql. Write web interface for DNS in particular.
In the future: Integrate the user management with the billing management.
Methodologies.
Too much time spent on interfaces makes too many special parts, and too much assembly required.
Too much time focusing on the whole with no thought of re-use makes a hard to maintain solid whole.
Too much time spent writing tests makes code that fails where the tests don’t cover
Too much time spent writing untested code makes code that fails where the tests should be.
Too much time focusing on the right way to make something Object-Oriented or Functional makes one forget the user interface, or worse, the user.
Too much time finding patterns means code that isn’t gets neglected.
Too much time just coding means ignoring the obvious patterns you repeat.
More web app ranting.
The theory is that one shouldn’t be able to tell what parts of a site are dynamically generated and which parts are static, except that the dynamic parts are dynamic. The W3 Style Guide makes some specific reccomendations. Dates as heirarchy make sense, because they won’t conflict over time, so you can keep the same URL valid forever, without namespace collision with future content. URLs specific to a certain set of server software should be avoided: no cgi-bin, no .cgi, and if your resource could theoretically be served up in a new content type in the future, no file extensions. It may be .html now, but maybe next year .xml will be in vogue, and ten years from now, .xht7 files will be the rage. If you leave it off and let MIME types do the describing.
For a web app framework, this means that whether or not to dynamically generate a page can’t be drawn from the URL in the general case. Should /products/foospray be static or dynamic? It should probably be static, updated when product information changes. Perhaps the output code would filter the page to include information about a user’s shopping cart, but hopefully that could be handled client-side, so that every user accessing the same URL at a similar time sees the same page.
One could probably conclude that locating a web app at a particular URL (or collection of URL space) is not the best option for flexibility. One needs a level of indirection for large sites, so that dynamic requests get handled by the right handlers, and static pages are served as fast as the machine can do it.
In an apache-like web server, I’d like apps to be able to be named independently of their URL, so that something like mod_rewrite can direct requests to the right app. I can imagine this registration resembling registering a remote procedure — after all, most web app frameworks have an entry point that looks remarkably like handle_request(request_object).
Perhaps it would look like this:
RegisterApplication shoppingcart /usr/bin/carthandler
Route "/products/([0-9a-z]+)(.*)" shoppingcart product=$1 info=$2
URLFor product,info "/products/#{product}#{info}"
It’s a little ugly, but I think it would work really well. The URL parsing is handled by the web server, where I think it belongs, but enough context about the request is passed on to the web app that it can make self-referential URLs without too much problem. How the arguments are passed to an application process is grounds for another rant, not this one which is more concerned with routing and URL spaces.
The neat thing about that is that one can re-arrange the URLs in the web server, and assign them a semantic meaning there. If one wanted to develop a standard for configuring these things in a webserver-independent way, that would be nice, but hardly neccesary if the app had enough information to just do the Right Thing.
I think a limitation of having user-exposed keys like URLs is that they are subject to configuration, not just being simple opaque identifiers. It’s not as simple as an auto-numbered field in a database. URLs have to be designed, not just created. Most non-trivial systems are going to have to have some configuration of their URL spaces, because auto-generation just isn’t going to get it right.
In the example above, the instructions for building a URL from a keyed set of information is provided in the configuration. This can be passed on to the app, so that it can generate URLs refering to itself and to others, without major hassle and with a central, well-defined place of control. No need to repeat yourself all over the code, or make undue assumptions (like that /appname/thiing1/thing2 is magically going to be self-referential.)
368
I remember why I don’t eat Bear Mush (cream of wheat or whatever).
It’s because I cannot focus at all afterward.
367
I’m annoyed that I haven’t had a dream that I can remember in probably a year. I don’t think I’ve had more than a handful since moving out of Colorado. I think that’s sad, even if my waking hours are dreamy.
366
I just watched Waking Life. Darn good film.