Blog Things
What do I envision for a homebrew blog application?
Well, my most import design parameter is that it doesn’t take much time to build.
I don’t want a writer/reviewer/editor permissions model. One user is good enough for me, in fact. If I want more than that I’ll install Wordpress or Textpattern or Zine or something. Hash a salted password with MD5 and slap that sucker in a config file.
It has to have a good name. Nothing exotic like Ubuntu or Django, but not exactly like BlogMaster or something. I wish “yaz” hadn’t been hijacked by birth control pills, because that’s the Turkish imperative for “to write.” This naming thing seems especially important in Python; it’s hard to compete with “Beautiful Soup” and the like. Maybe “Efendi” (Turkish for “dignified gentleman”).
But back to speaking somewhat seriously. No threaded comments, no pingbacks, no blogrolls. No API support. If I see XML anywhere outside an RSS feed it will be promptly be handed a lollipop and shown the door.
No storage of blog name, description, or owner in the configuration. Those go straight to the template. I have never understood the reasoning behind taking down a phonebook of information just to parrot it back through the template. Once. Maybe.
No need to actively manage files or images. A file listing with an upload box and delete buttons is ample. If that. Real men use SFTP. Clever men steal bandwidth from the original source. File management in any form would likely be a Version 2 feature.
Markdown formatting language, with HTML allowed for authored posts and disallowed for comments (I really hate cross-site scripting attacks). I’m sick of Textile for some reason. Possibly because it’s candidate #2 for the underlying bugs in Cluster 2.0.
No support for static content.
No plugin API. Here in NoFrameworkLand (or is it NoFrameworkLandFactory perhaps?), we call that a code revision.
No jQuery or other AJAX or sparkle. Please, no.
Okay, so that’s pretty much what it’s not. What is it?
RSS support. Not a Rosetta Stone of Atom, RSS 1.0, 2.0, 0.86, 26.a. Just RSS support.
Importing. Preferably via RSS unless Textpattern can’t accommodate. I started my blog at the beginning of my second year of college. With Blogger. The importer module will need some chest hair.
Data backend not exceeding the complexity of SQLite, meaning file-based database or flat files. Probably SQLite, probably with an ORM tool like SQLAlchemy to keep the actual written code terse (this is one place where I am newly receptive to accepting framework overhead).
Templates. Simple templates. I mean like str.replace(…) simple. Penance for the SQL framework comes from probably eschewing a prefab template framework. If there is one, it’ll be one of those lovely Pythonic one-file/no-install types.
The Clever Feature: “source merging.” Meaning the blog is capable of displaying data from sources beyond the basic sequence of postings. These other sources would be modular but would center around RSS feeds. What’s in mind is Cluster and Google Code integration, so updates show up like special blog posts and are commentable. This avoids the “Cluster Is Up” posting every time something happens.
E-mail notification of events. This is a low-overhead no brainer.
What’s that really missing? Spit-shine atop a text editor for making CSS files? I mean, what’s a blog but a way to compose, edit, post, and receive comments on your ideas?
I think a lot of your Drupal-type projects gain a lot of weight in their middle-aged time by trying to build scaffolding and decoration around inherently complex things. And the extreme case of any simplification effort is an equally-complex alternative for the original task. So, I instead recommend to embrace the complexity. Live on the edge!