These were notes for Lockers before it was even a real idea, focused on the idea of a web-based board game server. They're all vastly outdated but you may find them interesting.

  • Ruby on Rails?
  • Ikiwiki-esque system using SVN as DB?
    • svn slow -- requires precaching a whole ton of crap -- how much use is revisioning this stuff?
    • could statically render high-demand pages -- need to test svn perf.
    • if it works from a working copy, it becomes only as slow as file/dir access. Would have to come up with a fancy locking scheme. Also, to keep common access fast, old threads/pics/etc. would have to be moved to an "archive" -- just seperate directories, so that scanning all active stuff would be faster. Of course all links to old stuff would have to still work.
    • when you allow changes, allow more than one change to be gathered into one changeset, and then commit all the user's changes at once.
      • submit changes to a thread which just commits?
    • indexing? How do you search deleted things?
      • indexing is probably going to be difficult or impossible, but the good news is that searching is basically a big grep and so shouldn't be toooo slow (unless the site gets hit big.. benchmarking necessary)
      • searching the past could be implemented in two ways:
      • svn co a revision and grep that
      • search through the svn diffs (is this feasible?)
    • changes to things could be shown based on whether the old version was viewed. So if I update the location or time of the Anamanaguchi concert, and Chiz saw the old version, he will see "Ethan updated this" when he next logs in.
    • everything can have comments; comments are just files and so can be deleted.
    • comments need to be associated with the revisions, and should link to them
    • everything stored in svn but not necessarily editable
    • how is the user DB stored?
    • how about page views per person? SVN commit that?
    • if we store game states without moves, games will have to decipher what moves were made?
    • either store the moves, in which case, why not use RoR or something?
    • or don't store the moves, in which case, how will you see what was done?
    • we could store the moves in the SVN logs; this gives us "for free" version tracking and so is the best of both worlds.
      • "hidden information" stored in logs will have to be stripped out by game modules (placed battleship at B5)
    • if you store comments hierarchically, and comments move, old links to the comments cease working
      • move drops redirect pages, tracks referrers that hit that redirect page, and if none, deletes after certain amount of time?
      • We could just leave redirect pages all over the place.. profile before you optimize, etc.
    • in a MUD or something, committing every single move, item pickup, attack might be a bit much
    • Hmm, maybe have to keep track of certain non-committed data too?
  • One nice feature (of either implementation) would be allowing links to particular revisions of things -- this game at 4:00 PM yesterday, or before Eric's killing spree. I can't think that this would be useful outside of games though -- who cares what the forum thread looked like yesterday? I can imagine it by flipping through the posts that were made up until then.
    • you can't prerender all revisions of things, can you? I doubt it..
    • svn storage implies file access -- you could do some neat things with file-based access to threads, posts, etc. Reparent them with a move command to move them to a more appropriate forum, or "fork off" a new thread from a subset of posts? Well, maybe SVN would be handy to look into the past here, or add symlinks. Or maybe when a conclusion is reached in a sub-discussion, old conclusions can be removed? This is starting to sound like forum-blog-wiki convergence.
    • even if we don't delete posts, having links to the version that was commented on or replied to should be a nice feature.
    • if posts are threaded, you can't visually take posts "up to' yesterday
    • http://www.zopemag.com/Issue005/SectionArticles/articleRevisionManager.html
  • http://wordsandpictures.comicgenesis.com/d/20070227.html
  • gpg signing/encryption -> https and certifi.ca openid?
    • Using SSL with Dreamhost costs money
    • Is it good enough even if I don't?
    • drawing line between member of community and trusted person?
    • wiki with certain information viewable only by friends of a person? So, "B dated A until March 06" only visible if you are friends with A or B. Then the relationship status page of A (assuming you knew B) would just show that B and A dated and nothing else about A's history. But if you knew both B and C, and both had dated A, then both would show up on A's page. This way we can still extend our arms to new members, while not compromising anyone's privacy.
  • directory of cultural things (comics, TV shows, etc) that we recommend
    • Poignant Guide to Ruby, about 8 hrs time commitment, quote="Chunky Bacon!"
    • Penny Arcade, time commitment = 5 minutes every two or three days, rss=http://....
    • tabular output, sort by fields?
    • RSS feeds -- aggregation, central database

Blue Sky design by Jonas John.