Peer Pressure

Stuff to look at about looking at stuff. From Chris Dent. What?

Archive

Aug
6th
Thu
permalink

Recent TiddlyWeb Plugins of Note

Though the historical roots of TiddlyWeb are as a store for quine-like systems (I should write more about this), because it has a very flexible plugin system it also manages to be something of an unintentional web-app framework. Many plugins have been developed over the past several months. Many are experiments to demonstrate possibilities. Others are practical tools. Here’s a bit of info on those I’ve recently put together. Ben Gillies, Jon Robson, Mike Mahemoff, and FND have all been doing interesting work as well.

Just this morning I made markdown.py which is in the class of plugins known as wikitext renderers. These provide a method for transforming the text of tiddler stored in TiddlyWeb into some other textual form, usually HTML. The default renderer is called ‘raw’ and returns its input. TiddlyWebWiki uses the wikklytextrender plugin as its default renderer. It takes TiddlyWiki formatted text and returns HTML. The markdown renderer renders Markdown syntax to HTML. It’s possible to run multiple wikitext renderers in the same TiddlyWeb instance, which is used is determined by the value of tiddler.type. Here’s the entire content of the markdown plugin:

import markdown2

def render(tiddler, environ):
    """
    Render text in the provided tiddler to HTML.
    """
    return markdown2.markdown(tiddler.text)

ramstore.py is a StorageInterface implementation for TiddlyWeb that persists the main entities of TiddlyWeb (Tiddlers, Bags, Recipes, Users) into RAM in the same process. Persist is not really the right term because as soon as the current process goes away, so do the tiddlers. This plugin mostly exists for testing (it allows you to effectively mock a store without actually being a mock) and to demonstrate the bare minimum of what a store needs to be able to do to fully support the StorageInterface. Longer term, however, I can see it being useful as part of a layered caching solution (one thread reads or writes RAM and returns control to the web request handling layer, another thread wakes up when RAM is written and takes what is written and sends it downstream to more persistent layers).

The default distribution of TiddlyWeb provides no exposure of User entities over HTTP. userbag.py and users demonstrate two (incomplete) ways of exposing them. The former uses a combination of diststore and a simple StorageInterface implementation which presents the users on a system as tiddlers in a bag called ‘users’. The latter add /users and /users/{usersign} routes with handlers that query the store. At the moment both are read only.

Maybe I’ll write another one of these.

Comments (View)
Jul
14th
Tue
permalink

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.

Comments (View)
Jun
26th
Fri
permalink

Leaping Forward

I’ve been having a bit of a debate with @Casablanca about the need or merits of designing and developing for people who use Outlook or IE. It started with:

@cdent: This #fixoutlook thing is bullshit. Just don’t use outlook!

@Casablanca: @cdent it’s not about whether you use outlook. It’s about having to design for people who do (e.g. our client’s customers)

@cdent: @Casablanca don’t design for those people! Design well enough that they’ll want to use what you’re using. If U cowtow, they’ll never learn.

@Casablanca: @cdent you mean we should tell our clients to tell their customers to change their email clients? A bit impractical, no?

@cdent: @Casablanca Just because it is impractical doesn’t make it wrong.

@Casablanca: @cdent does that mean you’ve never tested code in ie, because you don’t want to design for those people either?

@cdent: @Casablanca I haven’t personally tested code in IE for several years, if ever. Nor do I test other code in non-posix envs.

My basic assertion here is that people or organizations won’t change to things that are better if they can get the cool stuff on what they already have.

A secondary assertion is that by requesting Microsoft fix Outlook, Microsoft is not getting the punishment they deserve for causing the problems they have caused over the last…well the last very long time. There shouldn’t be a campaign to fix Outlook, there should be a campaign to boycott Outlook and boycott developing for Outlook.

I understand the economic considerations involved in the calculus used to determine “shall we do the work to make this work in IE”. For people encumbered by relationships with the corporate world, it’s kind of inevitable that someone along the chain will declare an operating environment where things must work. Likely that is an environment where openness, consensual standards and interoperability are meaningless tokens, not thriving actors in the system.

I try to avoid those kinds of relationships, and think other people should as well. I’m well aware that some people can’t and some people don’t, and more power to them. In fact it works out quite well for me: Because I work on open code in open environments, if there are people who are interested in making the stuff I do work in non-standard environments, they have easy access to do so. The pain stays with the people who need or want to suffer it.

Yes, I’m being impractical. Yes, I’m being unrealistic. But I can see little to suggest that the practical realities of the world are the best ways of doing things, so I’ll continue.

Comments (View)
Jun
16th
Tue
permalink

S5 For TiddlyWeb

This evening FND and I were discussing how one of these days I’ll have to do a TiddlyWeb presentation: make slides, talk to people, gesticulate in awkward ways while standing in front of people and moving around for no particular reason. I remarked that I was going to use 3x5 cards to lay out my thoughts because they are physical and I think better with physical stuff.

This led to more discussion about how in the TiddlyWiki universe slide presentation systems are a bit of theme or motif. I said I had considered making a tool to present slides out of TiddlyWeb but figured I would do such a thing when I really needed it. What I had in mind was some kind of jQuery thing that retrieved content from the server as needed. In other words, a project, an investment of some kind. FND brilliantly suggested that an S5 serializer would be the ticket.

I had heard of S5 before, but never really knew what it was. So I went digging around and saw that the basics of S5 are not only incredibly straightforward, the fine folks at meyerweb.com have packaged it all up nice and easy.

So I thought to myself: All TiddlyWeb needs to do is make the s5 javascript and CSS available (either via the hosting web server, or the static plugin), gather some tiddlers, and push them into the HTML file provided for S5. I set about doing that and lo and behold it works! Here’s an example. Go have a look, it gives a bit of an idea of what’s going on.

And here’s the code.

The serializer architecture in TiddlyWeb has been designed from the start to be extensible. By configuration or a plugin you can associate a MIME type or a file extension with a Python module that implements at least some of the SerializationInterface. A serializer takes TiddlyWeb objects, such as a tiddler or collection of tiddlers, and turns them into some stringified form of some type (HTML, JSON, an S5 file, etc.). Some serializers go the other way as well (e.g. turning a JSON string into a Tiddler object).

The S5 serializer checks for some special tiddlers to set meta-presentation-stuff like title and presenter name, and then renders each of the tiddlers it has been provided into HTML. This HTML is then pushed into the template file (jinja2 is used) and the results are sent out over the web as an HTML file. That HTML file requests back to the server for the necessary javascript and CSS.

Because TiddlyWeb already has all the bits for generating the list of tiddlers and getting them to the serializer, the serializer itself can be quite small and concentrate on just the work it is supposed to do. The code is only 55 lines long, including whitespace. And I like whitespace.

There are still some things to clean up, but I reckon it is nice start.

Update: I updated the link to the demo to a new location to reflect that there’s now support for ordering slides in the presentation.

Comments (View)
Jun
11th
Thu
permalink
The GIF Pronunciation Page. It’s jiff. Here’s evidence.
Comments (View)