squaremobius dot net

The design of fuschia--1

What I think are good points about fuschia-0:

• The template system is small, clean and simple. Not sure about how arguments are represented (or whether there should be any), but we'll see.
• The arrangement of templates works well — using a document template, then within that a story template, etc. Might be useful to supply a standard 'use a template' function for customisers.
• Some of the utility (helpers) code is fairly reusable.

and points that need updating

• Keeping everything in the environment dictionary is just silly and makes the code messy. Most things can just be let in configuration, with variables really the only things worth keeping in the environment dictionary.
• Conceptually the storage/query abstration is in strife, probably from trying to be too generic. Better to assume more things and make things that are usable — 80/20, man. It's worth checking out gyre to see how queries are made there.
• It's too complicated even just to bootstrap. More assumptions, or better defaults. Relatedly, there could be far less code.
• I think I'm coming around to TonyG's view of the difference between caching and storage; caching is not a facade on storage, it's a facade on the model (or indeed, it is the model).
• Filters were just chaotic.
• Query parsing (and unparsing) is a bit ad-hoc and introduces problems with templates, though the code is probably reusable; needs to be thought through a bit more first.

I think the new way of going about things is:

• Base classes (the default for bootstrapping) can be 'in-memory'; subclasses of those might load from the filesystem, etc.
• Keep a caching model of the stories à la gyre; apply filters to stories when loading them (on demand according to the query).
• Bootstrap with some sensible settings but allow the user to override them immediately, as well as in per-query configuration.
• Make sure nothing upsets static rendering!

and open questions:

• Will I just end up with gyre with a few extra hacks (and should I therefore just branch from gyre)?
• How can I introduce some of the Zowian ideas about semantic-to-spatial relationships? Are they even in a state to be used?

Where am I going with this anyway?

Ever start something then realise you have no idea where you want to end up? 'course you have. You'll know how I feel about Fuschia then.

Fuschia started as a response to blosxom being, well, Perl, and PyBlosxom being, well, too far away from blosxom (yes that's right, you can't win with me). No sooner had I begun thinking about it than I formulated Grand Plans; for example, Fuschia will have a flexible and powerful template system and per directory configuration and … — you know how it is. And very soon after that, TonyG up and implemented his own blosxom-alike, citing irreconcilable differences. PALT.

So, it's back to basics: Is it worth rewriting Fuschia? What do I want it to do that isn't available elsewhere?

The first question I'll have to think about (and find time for). This is what I want it to do that's halfway novel:

• A templating system similar to blosxom, but 'safe' in that the template variables have to be supplied as such explicitly
• per-query configuration and templates, with usable defaults
• the opportunity to plug in different renderers, story filters, backing stores, and whatever else makes sense
• Static rendering that Just Works

As it stands, it is over- (and poorly) engineered, and sketchy as hell. With my new-found direction, maybe I can pull it back from the brink of untouchability.