tychoish, a wiki

tychoish/tumble-manager/ Questions Regarding Tumble Manager

Questions Regarding Tumble Manager

(This is like a FAQ but without the F part. Feel free to add things here.)

Why Tumble Logs

I've done some blogging concerning curation, and the value that people can create by filtering information into some sort of useful format. In a lot of ways pulling together resources even if the accompanying critical work (commentary, etc) is minimal, the curated collection is more valuable than the sum of its parts.

In a lot of ways, the tumble log, if done properly, represents an ideal format for the curation of the web. Tumble Manager, as part of this project represents the ideal tool to publish a tumblelog, by addressing a number of problems with existing systems (publication work flow management, type-based templating, and efficient software.) Additional blogposts of mine (tychoish) that have also contributed to my thinking include:

Why Automate Publication? Why Don't you use a Real Interface?

Tumble logs are high volume publications, but unlike (some) kinds of content management systems, every content item in a tumblelog is independent, and theoretically equivalent to every other item with regards to publication urgency and the only constraints on the order of publication are that you don't want a deluge of the same kind of content (e.g. links, youtube clips, quotes, etc.) to be posted sequentially. Furthermore ideally, a tumblelog (like all blogs) should aim to publish content in a regular, evenly distributed sort of way. If you post five posts a week or ten posts a day, it's best if those posts don't all get published on Monday morning or at 6:30pm PST.

Given these understandings, some sort of script is ideally suited to:

As for the lack of the interface, I imagine that eventually, I (or we) will want to create some sort of basic interface (probably in emacs or in a couple of scripts) that allow us to perform a number of functions: create a new post from a template, move a post from draft status to the publication queue, immediately publish a piece of content, and so forth. Beyond this I think the more interface there is the less powerful the software will be, ultimately:

The overwhelming success of the blog, was that it made the practice of "publishing content" to the web much less complicated and time intensive than it had been previously. There were people doing something very much like "blogging," before blogger.com and Greymatter appeared: what made blogging work was the fact that the software made it possible for people to spend much more time writing content, rather than editing a half dozen HTML files by hand. This project attempts to do the same thing for the tumblelog by automating the entire publication process, leaving the editors of the tumblelog to collect content (and hopefully do their jobs.)

What's up with the static/ directory?

There are a number of pages in any website that need to be managed with the content management system, but that aren't content items: the about page, the license page, a contact page. And so forth. I'm proposing that we have a top level directory called "static/" under which all of these files will be located, and there would be some web server configuration used to direct requests for, say c.cyborginstitute.com/about to public_html/static/about.html.

Why YAML and not something like RDF or XML

YAML is very easy to edit and produces a very human readable text, and good YAML libraries exist for most languages (though not for Common Lisp, but I want that to change.) I think storing data in a language agnostic sort of way is a good plan. And I have a personal objection to solutions to information structure methods that involve XML particularly in cases where I'd be expect to manipulate or write XML myself.