Miscellaneous Ideas

• posts, comments, articles, software, users, tips, links
• posts, comments, tips, and articles are fundamentally the same thing
• posts can contain a brief summary, software has versions, etc,
• posts are on the front page, articles aren't. articles can be much longer
• comments don't have titles, do have different rendering modes (limited html, plain text, bbcode or wiki??)
• redirects, errors, and 404s as exceptions!
• maybe a wiki-style history of changes to each post/article?
  • posts need a created, posted, and modified stamp
• lists section
• PGP keys as identity (possibly certs as well?)
• files/media/{images,videos,sounds} and respective media RSS feeds (use source to credit authors)
• markup with plain text, html, textile, bluecloth (maybe wiki too?)
• public, scratch-pad areas (wiki style)
• post-processing filters..
  • spelling
  • acronym
  • common URL
  • xmllint
  • profile (generate timing information on requests)
• hooks at different points in the pipeline to hook in modules
• ideas from FeedFlare:
  • most popular tags for this item via del.icio.us
  • tag this item at del.icio.us
  • Technorati cosmos: number of links to this post
  • Creative Commons license for this specific item. This works even if you are splicing, say, a Flickr photo feed into a blog feed and the two parent feeds have different licenses associated with them.
  • number of comments on this post (currently only for feeds created by Wordpress)
  • email this item
  • email the author of this item (particularly helpful if the item ends up spliced into another feed or repurposed on a site).
  • edit templates (ala WordPress)
  • hCard for users
  • hCalendar for events
  • ESF support
  • RSD support)
  • XFD support
  • Gruff for generating usage graphs?
  • Akismet spam support
  • use *_at for timestamps (ala rails)
  • use action/filter names for chains (ala wordpress)
  • accept posts via email

Page "Rendering" Pipeline

• request comes in
• check for session
  • session mapped to user, even if it's an ephemeral one
• get URI
• map URI into other URI (rails calls this "routing")
  • /rss => /feed/rss
  • /software/imlib2-ruby => /post/BLAHBLAH?
• map URI into action
  • /index => index handler
  • /api/rpc/VERSION.* => XML-RPC handler
  • /api/soap/VERSION.* => SOAP handler
  • /api/ajax/VERSION.* => AJAX handler
  • /api/rest/VERSION.* => REST handler??
  • /(post|archive|article)/POSTID => post handler
  • POSTID can be in the following forms:
    • DATE/IDENTIFIER
    • DATE
    • IDENTIFIER
  • IDENTIFIER can be in one of the following forms:
    • /^\d+$/ => post ID
    • /^[^0-9][\w\d._-]++++$/ => URI-friendly key
  • /feed => feed handler
  • /feed/rss.*, / => rss handler
  • /feed/atom.*, / => atom handler (extras include /feed/rss/tag/TAGID, /feed/rss/user/USERID, etc)
  • /tags => tag list
  • /tag/TAGID => tag handler
  • TAGID can be in one of the following forms:
    • /^\d+$/ => tag ID
    • /^[^0-9][\w\d._-]++++$/ => URI-friendly key
  • /users => user list
  • /user/USERID => user, comment and article history
  • USERID can be in one of the following forms:
    • /^\d+$/ => user ID
    • /^[^0-9][\w\d._-]++++$/ => URI-friendly key
  • /link(s|blog) => links page, with linkblog at top?
  • link to delicious/scuttle via Rubilicious?
  • link to technorati for individual links?
  • derive links from delicious?
  • multiple link "backends?"
• request, session, action, and view? saved to context
• action executed to produce "raw" result
  • note: should raw result be versioned for plugins?
• DEVELOP CACHING SYSTEM HERE
  • (maybe based on user/session and most recent object timestamp?)
  • returns 304 not modified based on if-none-match and if-modified-since
• template applied to raw result to produce rasterized result
  • probably use eruby for this
  • need to define
• result returned to browser

Post Process

• user auth
• verify render_as (markdown, textile, bbcode, text, html, etc)
• apply map, check for processing errors
  • for text, convert entities, gsub links, mailto, etc
• "scrub" result, depending on user level
  • admin gets no scrub, anything gets through
  • everyone else gets all but explicit list of tags and attributes removed
• cache rendered result
• post actual comment, entry, with cached rendered result

Scalable Interface Notes

• require cookies for auth only
*

Templates

• index
• post, article, archive view
• tag view
• user page
• account page
• admin page
• software page
• link page
• 404 page
• directory hierarchy
  • /theme/THEME/tmpl
  • /theme/THEME/inc/css
  • /theme/THEME/inc/js
  • /theme/THEME/ims
  • /theme/THEME/ims/preview.png
  • /theme/THEME/ims

Plugins

• plugins iterated over and loaded by hand on startup
• bad plugins shouldn't crash system, all calls wrapped in exception handlers?
• should have Sylph::Plugin.new or something

User Attributes

• username and password
• real name
• urlkey
• displayed name (alias, nickname?)
• icon
• passhash (and possible seed?)
• blurb
• web, email
• email is public
• theme settings
  • no_script
  • timezone
  • draw_icons
• filters
  • ignored_tags
  • ignored_users
• created date
• is_poster (can create posts, articles)
• is_editor (can edit comments, posts, etc)
• is_admin (can adjust page settings)
• OpenID authentication?
• (see notes in hnb for more)
• maybe a threshold for date vs frequency on tags? kinda wacky, i know)

Software

• short title
• short blurb (one line, no HTML, used for title attributes)
• full title
• blurb
• DOAP?
• examples/screenshots
• tutorial
• cvs repository / viewcvs link
• bug tracker
• versions
  • date
  • changelog
  • release notes
  • download
  • signature
  • manifest
  • manifest signature
  • documentation (maybe as PDF too?)
• should be able to sync to freshmeat
• should be able to sync to RAA
• should be able to sync to rubyforge

Menu Types

• title
• from menu entry (see below)
• from lists (see farther below)

Menu Entries

• name
• key (no spaces permitted)
• url
• script
• icon
• visible?
• position
• user_anon
• user_