14th
Tools Together
Brain Dump
As TiddlyWeb has matured, one of the things I have noticed is that people are often wanting it to do more than it does. The generic form of the query is something along the lines of “Wouldn’t it be more complete if it did X”.
This is interesting to me because in a way it is contrary to the TiddlyWeb point. At base TiddlyWeb is a tool for manipulating chunks of stuff called tiddlers on the web. It is one of many tools in the toolbox for doing web stuff.
An analogy may help. There are lots of tools out there that spin and accept attachments: screwdrivers, socket wrenches, drills, etc. You can make a drill be a screwdriver if you want, but sometimes it is overkill. TiddlyWeb is an extensible web service: with extensions it can serve up static content, use templates, do all the usual web framework stuff. But that doesn’t mean it should be used for all the usual web framework stuff. Maybe, maybe not.
TiddlyWeb comes out of the Unix tradition: small tools that do one job well and can be integrated with other small tools through pipelines. This is true in how TiddlyWeb can interact with other tools and also internal to the architecture of TiddlyWeb: separated layers with strict contracts for interaction. This means it is easy to extend and it interoperates nicely with other stuff.
The most performant and scalable implementation of a large scale service that involves TiddlyWeb likely involves TiddlyWeb; a separate web server (or two or three or four) serving static content, doing some URL rewriting, some caching; a memcached server; a database server; and maybe another framework (django, turbogears, rails, etc) presenting UIs that might use the TiddlyWeb server as a datastore.
This last thing (presenting UIs) is the main area in which TiddlyWeb intentionally makes no provision (to concentrate on effective backend handling). Good web frontend presentation is strenuous, there are existing tools which make it easier. A tool approach means that TiddlyWeb can play well with those guys.
