Ardekantur

So my school term is coming to a close very soon, and I’ll be able to get a little bit more work done on Canticore, which I’ve decided is one of my important projects that deserves my attention. I’ll be happy if I can add 50% more tests to the existing functionality, add a couple of important features, and solidify it all. The transition to Sinatra 0.9 allowed me to really clean up the code base, and I intend on continuing that refactoring until I’m satisfied with it.

Two threads of thought have occupied my attention since I stopped working on Canticore. They both have to do with perception and functionality of blogging engines, and they both kind of merge into each other. The first is the decision whether or not to include an web-based interface for writing, editing, and managing posts. Just like one of NetNewsWire’s design goals was to allow a person to literally have a coffee in one hand and read the news with the other, one of my design goals is to allow people to interact with Canticore in a comfortable environment. The song-and-dance of working in your favorite text editor and then copying and pasting your output to the web-based interface is anachronistic. We have our text editor, we have XML-RPC. Theoretically there should be nothing stopping us from keeping an arm’s length from the administrative process inherent in a web interface.

And if Canticore starts becoming a publishing platform instead of just a blog engine through its plugins, there’s nothing stopping plugin editors from defining mini-specs that would interface with a canticore command-line executable. Suppose, for example, a plugin existed that created a ‘featured’ list of articles like you see on many pages — an series of images and blurbs that transition from one to the next indefinitely. Ignoring for now the problem of uploading the media, the plugin could define a namespaced XML-RPC request that took a set of arguments. For our purposes, a 3-tuple of arguments for each ‘feature’ article will suffice:

  [
    { :image => 'garden.png', :blurb => 'Lorem ipsum...', :link_to_article => 14 }
    # ...
  ]

Canticore already contains an XML generator for the most-used data types in Ruby, so if these 3-tuples were defined in a YAML document, we could perform something like the following:

$ cat features.yml
--- 
- :image: garden.png
  :blurb: An article about gardens...
  :link_to_article: 1
- :image: cleaning.png
  :blurb: An article about cleaning...
  :link_to_article: 4
$ canticore --blog myblog --post pluginName.sendFeatures < features.yml

And we could receive a status message from the plugin as to if the features list was well-formed, if it could find all the necessary images and articles, and so on.

Now we’ve managed to segue into the second train of thought: a canticore command-line client. It would help generate blogs, retrieve information about them, and allow people to automate any task necessary for blog maintenance. It would include a Ruby API so it could be called from Rake scripts and the like, and we could throw it into crontabs whenever necessary, constantly building on the software that works well and already exists instead of trying to reinvent the wheel. The practical upshot of this is that people would have the ability to keep their articles locally, under source control, and even provide post-commit hooks for publishing, like some prominent content publishers in the Ruby arena seem to focus on (Jekyll, in particular).