The TODONE file

[tangaroa]

While looking through old files, I found a TODO list so old that I've actually done most of the things on it. Usually these things double in size every year. I shall celebrate with a mocha.

• Convert my introduction to libxml2 from text to HTML -- I did that in 2003 and I forgot I did that and just did it again as part of my cleanup efforts.
• Add a rewrite rule to my college website -- the school wouldn't allow it, but I've done some work on the backend to rewrite local links into a pretty-URL format that mod_rewrite could then translate into the expected CGI variables.
• Fix a CSS bug in my website that appeared in IE6 and Konquerer -- any bug that old has likely been squashed by now and these two browsers aren't worth supporting anymore.
• Check my links page to see which are broken -- hahahaha. This is still a TODO.
• Move CSS rules specific to certain pages out of the common layout CSS file and into custom files -- I did that.
• Automatically generate and add a table of contents to the sidebar menu when viewing my links page. -- Still a TODO and worth debating if it is a good idea or not.
• Fix a CSS bug that is marked as fixed in the TODO file. -- okay.
• A drawn-out proposal on adding support for selecting alternate stylesheets -- I did that a long time ago.
• Fix problems with the implementation of page titles and headers -- I changed the way these are handled, so now there are a different set of problems to deal with.
• Convert the website from a server-side application to a client-side application that keeps the outer layout divs and uses xmlHttpRequests to fetch page content from the server -- today being a staunch advocate of letting pages work without requiring Javascript, it surprised me to see my younger self proposing this. My plan was to keep the backend around for non-JS browsers and have Javascript convert all of the relative links into http request functions. One potential problem is that different pages would also change different parts of the page, but this could be easily solved today by having the server-side entry point send back key=>value json of {header: ..., title: ..., content: ...} and letting the script replace the appropriate content. Another problem that would arise on a site with pretty URLs is that the client cannot distinguish between URLs that will be rewritten to application-managed content and relative URLs that refer to separate page content that should be viewed on its own (mod_rewrite does this with a RewriteCond ... -f rule). The server entry point can handle this by checking for the existence of the file, but this leads to a third security-related problem. Pages may normally refer to "../etc" and when the javascript sends this request to the entry point, it may have trouble distinguishing between legitimate and hostile requests.
• Offer the user a way of selecting a different stylesheet -- yeah, that was easy. Just a dropdown box and &style=foo.
• Use mod_rewrite rules for pretty URLs -- apparently I really wanted to do this, but the admins would not let me.
• Write a script to build static cached pages -- with the added note of "practice /. defense", this is still a TODO. I've added enough variables that can cause page content to change that this may become difficult. A plan may be to first list all of the variables that could cause a page's contents to change, build a unique value from the list, and store cached files at cache/$value/$contentID. On the non-technical level, back then I was so certain that I would write something popular that I viewed the website's lack of optimization as a serious problem.