One of the tools I love to use is Tinderbox. The homepage says: “Tinderbox is a personal content assistant that helps you organize, analyze, and share your notes.”
I just downloaded the latest beta version (3.6.3 b17) and found that it has a list of improvements that push it forward again.
If you never heard of Tinderbox try looking at some of the screencasts that are online.
Tinderbox is a tool that has been around for ages now and while the technical progress is slow compared to other tools it remains unmatched for a lot of tasks. The sad part of it is, that it does have some limits and missing features that people expect from a writing tool. But besides of that it’s potential has not yet been fully exploited by its community.
The tricky thing with Tinderbox is, that it does “take off” unless you know how to use the tool wiseley. For a newbie it may feel like just another note-taking tool that misses some core features. But once you discovered some of the core concepts of Tinderbox a whole new set of options.
Findamentally it is a tool that keeps asking you: What do you want to do with your thoughts? How do you create relevance out of randomness? What does order in a chaotic world of fragmented information mean?
Tinderbox somehow forces you to answer these questions and define a concept how you want to process everything you write down. You may start with no such concept and try to develop it while playing around with Tinderbox. But once the level of interdependence of notes, actions, templates and such gets high (which can happen quickly) you need to become smart about how you manage you material.
After I sucessfully imported some parts of my old weblog I reconsidered the idea to publish with Tinderbox to a database instead of using it to render HTML. Here is the current idea:
- A Python script will read the Tinderbox file and publish this into a MySQL database
- The database will be synchronized with a copy on the server
- The server uses Zope to publish content (but can use anything that works with MySQL)
- Server will use meta data, link data and possibly other things to create the site
- No need for agents anymore, the searching/collecting is done entirely on the server
- No need for export and rendering from Tinderbox
- A wider range of possibilities when translating data to HTML (full scripting)
- Agents and HTML export is still possible – e.g. to keep a “internal work site”
- Can possibly be extended to work for other environments
- Possibly opens a way to use other ways of translating ASCII text to HTML (e.g. ReStructuredText or Textile)
- Could allow many authors to contribute to one site (but not edit content created by others)
- Obviously there is code needed
- Needs Python and MySQL on the client and MySQL on the server
- Concept for a database structure and content specifications needed (how to use actually information from the Tinderbox file in the site)
- A great deal of development needed on the server to turn the database into a site
- Changing the Tinderbox file a lot could break the system
- It is a one-way process – so no edits on the server travel back to Tinderbox
I investigated PyXML and elementtree which I found via Uche Ogbujis article on XML.com. I also found this XML & Python tutorial by Alexandre Fyolle very helpful. This Devshed tutorial on MySQL & Python reminded me about how to connect to the database. All this worked pretty well in first experiments.
The translation script will have to do some heavy work:
- Translate Tinderbox commands (or invent own)
- Maybe convert links and styles
- manage images that are inside the Tinderbox file
Right now I set up this weblog to be rendered on my laptop and upstreamed to the server with normal HTML pages. This somehow put the burden of organizing the site on Tinderbox. But somehow I get interested in the idea to let the server care for the public face of my content and rather use Tinderbox in a “freestyle” way. The server should only get a “content feed” from which it should construct a site.
One rather simple way would be to publish the Tinderbox content directly into a database on the server. The quickest (and dirtiest) way to do that would be to render SQL files and use a script on the server to import these. The HTML rendering would be completely the job of the server (and of course I’d need to set up templates & everything there).
A more sophisticated approach would be to render XML files that are parsed into the database. This would maybe allow to reduce the amount that needs to be uploaded per update.
Unfortunately I don’t think I am going to have the time to check this out. But somehow I hear a distant voice telling me that this would even allow several Tinderbox users to work on one site together (or at least publish into the same space).