Update 20130122: So it turns out that my predictions about the expected uses of TiddlyWeb, especially with regard to the management of HTML presentation, were not correct. In the
1.4.x version of TiddlyWeb, HtmlPresenter was removed in favor of the HTML serialization providing the full HTML document. There’s a related google group thread.
I read somewhere, long since lost, someone talking about what happens when you start integrating web, REST and WSGI styles of thinking, designing, and developing into your brain. The result is much the same as what you get if you came of technological age during the ascendency of the Unix Pipeline.
This thinking is variously described as right tool for the right job, one tool that does one thing well, pipelines, one liners, compartmentalization, separation of concerns, lego, simple grammars leading to complex behaviors, constraints will set you free…
WSGI makes it possible to stack little web services on top of one another. On the way in you can modify the request environment and context, making choices and adjustments as required. On the way out you can modify the response, headers and content in as simple or complex a manner as required. Each pass through the service stack is in the same process space but the specification encourages the use of only three known entities: the request environment, the response headers and the content being delivered.
It’s very easy to share data globally if you like, or with objects passed around here and there, but if you imagine each WSGI app as its own server a sort of radical simplicity and separation can emerge. Each service is a world unto itself, a world so seemingly complete and perfectly contained that when someone wants a change to the world it kind of goes like this:
them: How about you make it do X? us: No. them: Why not, all you need to do is Y? us: It doesn't do that. them: So. Change it? us: No, see, it doesn't _do_ that. them: That's kind of lame. We need X. us: I'll make something else. Something that does _do_ X.
Now it may seem like us is kind of a jerk here, but us, who is really me, has discovered that the sort of architecture that leads to this thinking is very easy to test, to build, to deploy, to maintain, to extend. It’s got good lego characteristics.
This scenario played out, a bit, in real life today. TiddlyWeb is primarily designed to be a data store and provider for the generation of dynamically created aggregations of Tiddlers. You can store tiddlers and get them back in a variety of representations.
TiddlyWeb is at core a WSGI application using selector for dispatch. Surrounding that core are about ten other WSGI apps handling tasks like content negotiation, credentials extraction, exception handling. When a
GET request is made the request entity is retrieved from a
Serialized into a representation.
From quite early on in its development TiddlyWeb presented HTML representations of its various resources and collections thereof. In addition to being a useful representation for other tools, HTML makes it possible to browse around the TiddlyWeb service and see what’s there.
To make this work in a hurry the HTML serialization system created full HTML pages as representations. As people have played with TiddlyWeb they’ve found the pages useful and wanted more on them: they’ve wanted TiddlyWeb to act like a web site.
My response to that is the hopefully predictable by now “no way, man, TiddlyWeb doesn’t do that”. TiddlyWeb is supposed to be a web-service not a web-application. My dogma, however, doesn’t change the fact that a clean and usable presentation of TiddlyWeb content is useful nor that people are used to and gaining benefit from the HTML presentation TiddlyWeb already does. So something needed to be done.
One method already exists: TiddlyWiki presents TiddlyWeb content very well. This is not surprising as that’s what TiddlyWeb was originally built to do.
The method I prefer is some other web application that wraps TiddlyWeb in a luxurious and usable HTML embrace. This hasn’t happened yet, but I’d like to try it with django soon.
The other server method is not great for some: it presents administrative and technical challenges dealing with installation and authentication complexity. So a third option is to build another piece of TiddlyWeb, separate from the core, which can be used for beautifying the HTML output.
I such a tool today and I think it is going to work out pretty well. It puts one job in one place (an
HTMLPresenter) and make the job of the HTML serialization tighter, more in alignment with its real purpose: Turning a resource into an HTML representation.
HTMLPresenter is an optional and replaceable wsgi app that watches outgoing responses. If it detects that they are HTML serializations of resources, the representation is wrapped in warm loving HTML provided by the
HTMLPresenter is a replaceable piece of code (by changing the config file) and because it is in TiddlyWeb’s wsgi stack, an installation can make the presenter be whatever is needed. The default one sticks a header and footer around the provided HTML. One that was more interesting could use a templating engine, suck in content from elsewhere, present user dependent data, whatever.
Or, if you want, you can get rid of the HTMLPresenter entirely and let something else worry about it.