I hope soon to begin implementing a comment system for ongoing. This space is my notebook where I’ll work out the design. Since, as of this writing, the system exists only in theory, if you have a suggestion you’ll have to send me an email. I’ll publish the helpful ones. [Update: Tons of super-intelligent comments, informed by (sometimes bitter) experience. Thanks! I’ll publish them, but a couple of things emerge. First, I do have to plan to fight spam. Second, I should have a look at camping.]
Goals · First, I think ongoing would be better with comments.
Second, I’d like to take this occasion to learn at least one new technology.
General Outline · For every ongoing fragment, there will be a little directory tree, containing one subdirectory each for incoming, rejected, and accepted comments. The comments will live in these directories, one file each, with long names consisting of a timestamp and a random number. These directories will generally not be publicly Web-accessible.
All comments will always be moderated. There will be a simple Web interface offered to people to compose comments, and another for me to use to approve or reject them. I’m not inclined to building a safe HTML editing control from scratch, but will look around for components that will let people compose somewhat-rich comments without involving extra work or risk.
Comments may be submitted and (while still in the incoming directory) deleted or updated using the Atom Publishing Protocol, although I’m not sure how useful that will be.
Every time a batch of comments is accepted, all the accepted comments will be built into a static Web-accessible page and a small XML file will be created containing the number of comments; this will be used to decorate the body of the fragment via XMLHttpRequest.
There will be no built-in authentication system, because the Internet has enough of these. I will, however, eagerly participate in any shared-identity system that seems standardized and doesn’t feel like a vendor land-grab. The use of such a system might make the Atom Protocol useful rather than incidental.
The comments will be threaded; that is to say, you will be able to attach a comment either to an ongoing fragment or to another comment.
Issue: Release? · I will never release the core publishing software for ongoing to the world, simply because I wrote it in a big hurry and with no other objective than supporting my idiosyncratic writing workflow. However, if this comment system proves to be useful and generally applicable, I’ll consider releasing it.
Issue: Spam · I suspect that I will not be subject to serious, automated, large-scale spam attacks, simply because the number of instances of the system will, initially, be one. However, because I might decide to release it, I will design in a plugin-based spam-fighter module.
I have some ideas about spam-fighting approaches that I haven’t seen anyone else try.
Issue: Platform · I am subject to the seductive emanations from the Rails Rabble, and one of the reasons I thought I’d do this was to learn it. Having said that, try as I might, I don’t see why I’d need to use a database, and Rails’ sweet spot is generally considered to be database-backed apps. On the other hand, I have an intuition that in a few years, Ruby the language is going to loom larger than Rails the framework; so I definitely want an excuse to get up close and personal with the language.
So, I dunno; does Rails offer enough other good things to make it an attractive choice even if you don’t need a database? There’s all that model/view/controller goodness, but I’ve always found the MVC approach a little more attractive in theory than in practice.
Hmm... the jury is out. Is there another framework whose sweet spot is a little less database-centric? Or is Rails the way to go?
