tears in rain

I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near the Tannhauser gate. All those moments will be lost in time, like tears in rain. — Android Roy Batty's meditation on the shortcomings of his content management system from the motion picture Blade Runner (Scott, 1982)

Tears in Rain (tir) is a personal content management system with the following features:

• File system mirrored on web server, shell server, and client device.
• Comprehensive file navigation on all platforms by file system directory, category, update chronology, or title index.
• File contents regular expression search.
• WWW access control with basic authentication.
• File creation and manipulation with ordinary client device or shell host tools.
• Simple linking between served files.
• Customizable shared styling of navigation pages.

Enhancements for possible later development:

• Text file creation and editing through WWW browser.
• Comment mail form.
• Wiki markup?

tir features are inspired by MUDs, gopher, blogs, and wikis, and seek to capitalize on Unix shell tools for content development and site maintenance.

Name Change

The name of this project was changed to Tears in Rain during development on 2006/6/29. The project was originally named M21 for one of the author's web sites, Twenty-First Century Meyer.

Purpose

How many hours, days, weeks of my life have I spent searching the Internet in pursuit of my latest dream, winnowing kernel from chaff, discovering wonders, only to bury them again in a bookmark file to be forgotten and lost? How much time have I wasted searching again for pages I've found before and forgotten? How many dreams abandonned when I've let the trail cool and the strands of information fade from memory?

Tears in rain. I do not want to lose these moments on th Internet yet. I want to hold them, connect them, consider them from other angles and times. I want what I have discovered to be useful to others with similar interests, even if I never pick it up again.

tir will be a simple way to capture, organize, link, and retrieve thoughts and information on a wide range of topics of passing or long-term interest to me. I am writing for myself, for distant family and friends, and for would-be friends across the Internet who share those interests.

Navigation is Key

The Internet serves a universe of files (documents, images, videos, etc.) each accessible with an unambiguous address specifying transfer protocol, host, and resource identifier. In its basic state the primary constraints on the Internets usefulness are the requirement to know an address to access any file, and, even when having the address for some file, the lack of a systematic means for discovering addresses for related files or obtaining a catolog of resources available on a given server.

gopher, an Internet service that was a precursor to the WWW, provided navigation among files hosted on a server by exposing the server file system directory hierarchy to remote users in the form of menus. Users could choose from a list of files in a given directory, or choose a subdirectory for a list of corresponding files.

This project began focused on the development of a wiki-to-HTML markup converter but this approach was abandonned in part due to the realization that an efficient, flexible, and comprensive navigation system was of much greater utility than the small efficiency gain in file creation and maintenance that would be achieved through markup simplification.

Issues

• Should program and configuration files in the tir mirror set be directly run or referenced by production programs, as I do with cavenet (e.g. TinyFugue scripts), or should there be a process for installing tir mirror files into production configurations?
• Should the tir site root correspond to a) the HTTP site root, exposing utility directories (cgi-bin, etc.) to tir, or b) some subdirectory of the HTTP site root, hiding files outside that directory subtree? I'm leaning toward a) due to greater personal utility and potential for shorter paths for intra-site links. (Though security is a concern with complete openness, it will be good to develop the discipline to think of security when I upload a file instead of trusting to obscurity and luck. I think most files on my site are already exposed through the web server's default directory list anyway.) NOTE: must be cautious during initial set-up. Making tir root same as web site root will likely cause attempt to mirror all current web site contents to my Zaurus, which is an impossible several hundred megabytes of data.
• A subdirectory of the tir root will be created for each topic/category/theme regardless of relationships existing between themes. Relationships between themes are represented with file system links (hard or soft?) created in the themes' subdirectories. This gives benefits of subdirectory partitioning (ease of working on thematically related files as a group, reduce file list clutter, allow shorter file names due to implicit qualification by directory name) while keeping intra-site document links as short and easy to remember as possible (file name only is relative link to document in same theme, "../Theme/Document" links document in another theme).
• Wikis demonstrate the importance of file naming. Having a simple, at-a-glance transformation between file names and thematically significant terminology greatly reduces the mental effort of creating and maintaining content and the site as a whole. I am leaning toward standardizing CamelCaps file names similar to Ward's Wiki to reduce name length (no inter-word space or underscores) and to distinguish content subdirectories (name capitalized) from utility subdirectories (lower case). (Hoping to use .file names to hide from file lists.)
• HTML files generated by tir must contain relative URIs only that are valid on all platforms. File paths (possibly platform-dependent -> configurable environment variables) may be used in scripts, but must not appear in generated HTML.