Peer Pressure

I’m beginning to think that the enterprise 2.0 concept of moving activity and information sharing styles like Twitter and Facebook into the workplace is based on a flawed concept or assemblage of concepts.

We’re all familiar with the idea that knowledge workers do their work around the water cooler: Picking up what they need to know via their network of friends and connections.

And we’re all familiar with the notion that Twitter and Facebook (and tools like them) can act like a virtual water cooler.

But there are a few problems here:

• Some organizations go ahead and use Twitter and Facebook as the water cooler. No thanks, I don’t want to mix my work and other lives that much.
• Some people don’t drink “water” and these people may be exactly the people that either need or have the information that needs to shared.
• Social networks are cliquey and exclusionary and operate on the pride of knowing, sharing and being in on the latest thing. Sounds a great deal like the old boy network of back scratching, graft and secret handshakes that makes the business world such a cesspool.

Being in on the latest thing is a competitive advantage. If an individual knows the latest thing it is a competitive advantage for them versus their coworkers. If an organization at large is in on the latest thing it is a competitive advantage for the entire organization. If an organization thinks everyone is in on it, but only some are, then there is a greater risk of the ball being dropped than if nobody was in on it.

So: There has to be more than the water cooler. There have to be artifacts that are curated and effectively shared.

I’ve long had a problem with Twitter and Facebook. They clearly do awesome things, allowing people to communicate in many great ways, but they get in my craw: They end up being a disturbing combination of TV and High School; a race to the bottom where lie the spammers, the advertisers, the popular wit, the need to consume and the need to capitalize and control. The glorious potential of a deeply and diversely linked web of hypertext lost to a bland linear experience.

There’s nothing too horrible about any of that, but I just don’t like it. It’s not good enough.

Further, especially with Facebook, once you stick your content in there, it’s obscured behind an interface that limits access, reuse, sharing and improvement.

So in addition to this blog I’m going to do some social networking experiments on TiddlySpace, the thing I’ve been working on for the past few months.

TiddlySpace is an extension to TiddlyWeb and TiddlyWiki, joining them together with code and UI that provides a multiuser platform for creating and sharing information that is a first class member of the open web.

It’s not really all there yet for doing social networking, but experimenting with will help reveal some of the holes. Some that already exist but will likely be solved eventually:

• No support for OpenAuth.
• Atom feeds from the service are not well exposed and when discovered the content is not fully useful.
• The HTML presentation of individual entities (outside of a TiddlyWiki) is tepid.
• There is no easy support for commenting or otherwise annotating existing content on the content.
• http://tiddlyspace.com/ is yet another new silo.

These last two are perhaps the most interesting. The long term plan for TiddlySpace has solutions.

TiddlySpace already supports a concept of following: users on the system can follow one another. When people who follow one another create a tiddler with the same title they are notified of the existence of the other tiddler and can easily view it. With this awareness they can asynchronously communicate about the topical domain of the tiddler, evolving each others’ views. As following evolves the hope is that it will allow a spam free way to enable synthesis.

There are at least five running tiddlyspace servers, but at the moment they are all independent silos. My content on tiddlyspace.com is currently at the mercy of the administrators of that server. At that moment that is me, so not a big deal, but for other people I think it is. My content, for example, can presumably be subpoenaed without me being able to dispute it.

Long term TiddlyWeb (and thus TiddlySpace) will support a type of federation that allows disparate server to share content. In the Chris Dent perfect internet, everyone would have their own server (or an IBOC). For TiddlyWeb this means being able to read remote bags when processing recipes. For TiddlySpace it means having a federated database of username and space maps.

If you want to join me in this little experiment you can do any of the following:

• Visit http://chris-dent.tiddlyspace.com/ to see my “space”.
• Visit http://tiddlyspace.com/ to create your own.
• Subscribe to my tweet feed or look at the html list
• Subscribe to my journal feed or look at the html list

You’ll find a fair few rough edges but it will get more smooth with time, especially if people let me know.

Some time ago I called myself an information theologist.

I spend a lot of time thinking about what motivates people to do work. In the BlueOxen days we discussed that collaboration required SharedLanguage that led to SharedUnderstandings that led to SharedGoals which result in stuff happening.

This all remains true but I think there’s a step at the end which deserves more attention. When presented with the opportunity to do something, why do we actually do it? What is the process that drives us to choose between “yeah” and “meh”?

I think it’s belief. Faith. Allegiance to something that orients the moral compass. For some that’s just as simple as “it’s my job and I’ve got a work ethic, let’s get on with it” but for most that’s not really enough. There’s usually something more like “my paycheck feeds my kids” or “if we make this thing we are making the world a better place”.

In the abstract world of developers, things get a bit fuzzy (because many of the “normal” motivations don’t seem to apply) and I reckon that developers come up with methodologies to provide themselves with the structure, no, dogma with which to motivate themselves.

All methodology things like XP, Agile, scrum and even waterfall are is religions. A moral compass. A basket of constraints. A third party authority to get you off the hook and moving.

Similarly, all the standard religions are is methodologies: Ways of structuring your daily and otherwise life so it is functional, palatable and in motion.

A cut from a google groups posting about TiddlySpace:

The advent of wikipedia has meant that recent aspirants to the wiki way have a sense that a wiki is a reference, an information resource, which has evolved out of the concerted effort of many editors.

That’s a great thing, but it’s not a wiki.

A wiki is a synthesis engine. A tool in a community. It allows an individual or group (usually smallish) to discover the gaps and connections in their understandings and then through exploration of the network and comparison of the nodes, fill in meaning. This means that the most important features in a wiki, for learning, are: LinkAsYouThink, BackLinks, RecentChanges, and whatever you want to call what TiddlyWiki reifies as “Missing”.

Or Purple Will Rise Again!

I went to the London Wiki Wednesday yesterday. Jeremy gave an overview of TiddlySpace. Afterwards there was some discussion of how it is different from other so-called collaboration platforms (Sharepoint being one of the examples of things that do it wrong compared with TiddlySpace’s version of right). I suggested that the difference can be discovered by thinking about which nouns have a primary position when describing or thinking about the platform. I suggested that whereas Sharepoint gives primacy to groups and documents, TiddlySpace likes individuals and information.

On the train ride home I realized that this maps well with my views on the actions that are occurring when people augment their collaboration with tools. Obviously there is a group involved—or it wouldn’t be collaboration; but the interaction between tool and information pivots on individuals. Some one reads something, or writes something, or synthesizes something. Each individual member of the group accesses that something, that granule of information, and integrates it into their understanding.

Therefore the job of a collaboration tool is to assist in the creation of granules and augment their distribution and presentation to the individual members of the team so that they can then be used to a) integrate them into their own knowledge or understanding, b) use them to create more. If a system is architected at the level of a document, it is too high level: composition and decomposition of the granules of information which make up the document becomes a major task in the use of the system. Besides being a time waster this is an ineffective use of the computational and cognitive resources that are available.

Computers are really good at moving around and re-presenting information in arbitrary ways. They are not good at composing meaning out of disparate parts. People, on the other hand are really good at composing meaning out of parts; all day long that’s what the brain does. It seems likely that to a very large extent, spending time composing documents for transmittal is a waste of time. We (humans) can and will synthesize our own composition (effectively a virtual mental document) from the relevant parts, especially when able to use tools that allow us to move things around and play with re-presentations.

On the occasion of relocating home to places more rural and secluded as allowed by the memex.

My job description, for the last twenty years or so, has been primarily concerned with the creation of hardware and software systems. My work product, however, has been the creation of artifacts of communication; communication with humans. Everything I’ve done has been the result of the exchanging, processing and encoding of ideas in various forms which can be used, immediately, or later, by other humans I’m working with now, will be working with later, or who will be working with stuff I was involved with but I’m no longer around. No longer with the company. Expatriated. Dead.

These days I write a lot of code. Code tells a computer what to do, but more importantly code tells a story. It narrates, for future maintainers, the intent of a system. Code is communication. For humans. Code could be Pynchon or Joyce or Faulkner, but you’re really better off trending in the direction of Fitzgerald (after he got past the fun the of This Side of Paradise) or Hemingway and then stepping down several reading comprehension levels to something nice and simple, so you and yours don’t feel dumb when you go back those few days or weeks or months or years later.

I have not had an office away from home for several years now. As a fully paid up member of the knowledge economy my job is to think, state some theses, and produce something antithetical to that which crosses beneath my baleful gaze. My communication is most useful to you when it persists. Your communication is most useful to me when it persists. If there is no record, then any participants not present are shit out of luck.

From out here in my pastoral paradise, this is as true as ever, and it is good. I am trained up in how to do this. Time and distance are no barriers when persistent and addressable information artifacts are being tossed around in an asynchronous ballet of packets passing. In collaboration with like minded folk around the world I get things done with less waste on the dimensions of space (this is my footprint, I live in it), time (yours and mine) and energy (mental, physical, environmental).

I’d like to think this is the future. The economic advantages for me and for the companies that might partner with me to make things happen ought to be huge, especially once many people are doing it. The environmental benefits even more so.

Unfortunately, I’m one of a privileged few in a country that itself is one of a privileged few. Is it right to carry on and trumpet the benefits maybe creating some gravity, pulling a trend? Or is there some better way?

In late March, early April, I was feeling like I needed to make something. My normal role is making things that are used to make things: backends for web-served stuff. I got into such things because I’m devoted to the idea that an open web that openly serves information open to interpretation opens doors to knowing, being and doing more. So there in late March, with those thoughts in mind I created a thing called manifestopheles which is a front end over a TiddlyWeb store of tiddlers.

Thinking about manifestopheles made me realize that I’ve been so focused on TiddlyWeb for last long time that I had rather lost sight of some of the reasons why I’ve been working on it. Once back in the mood of thinking about those things I allowed myself to be volunteered to present at the 8th Open Source Show and Tell. Here’s a video of me ad-libbing alongside some slides managed by the excellent TiddlySlidy.

Chris Dent presents…Manifestopheles from Phil Whitehouse on Vimeo.

Despite my dancing, ums and uhs, and bad posture, it seemed to go pretty well.

That presentation was centered around why I created manifestopheles: a demonstration of the importance of context (a social thing) in the acquisition of knowledge (a very individual thing).

The following week at TiddlyChat I said a few words about how I creatd manifestopheles. It’s an example of something that uses tiddlers and TiddlyWeb without using TiddlyWiki. It’s a simple HTML presentation with a smidgen of jQuery and CSS diddles on top to enable the interaction. The TiddlyWeb HTTP API does all the real work.

There’s another TiddlyChat coming up next week (Tuesday the 18th of May) at the Osmosoft offices.

The XHMHttpRequest working draft includes this gem about handling redirects:

If the redirect does not violate security (it is same origin for instance), infinite loop precautions, and the scheme is supported, transparently follow the redirect while observing the same-origin request event rules.

Modern browsers appear to handle this correctly. Cheers to them for following the spec. However, this is quite the pain when you want granular control, from the client side, of whether to follow the redirect. If you want that control, you’re pretty much SOL without changing the server. The redirect gets followed and the response available is the response to the second (or subsequent if there are more than one redirects) request.

From the server side you could detect that the request is an XHR and send a different or special response code which the client could then interpret as needed, but that places complexity in the server that should be in the client.

In many cases, following the redirect may not matter. The client side can ignore the content and carry on as it needs but there’s something sort of fundamentally anti-web in this act of transparently and magically doing more than one request from a client-side programming environment. The fundamental granular piece of the web is the one request/response interaction.

I wrote a paper about HTTP in TiddlyWeb for WS-REST 2010 and today learned that is was not accepted. Based on the comments in the reviews as well as the titles of those papers that were accepted I think this is an appropriate decision on the part of the program committee. While there is a general consensus that the paper is well written and interesting (3 of the 5 reviewers say the paper was the best they reviewed), there are concerns from some reviewers that it does not make a substantial contribution to the academic field. That’s probably true.

So while it is a bummer the paper did not get accepted, it is very nice to have the comments from the reviews. They were quite enlightening. I also now have a paper I can stick on my website. Please read it if you are inclined and if you do, I appreciate any comments you might have. The official title is TiddlyWeb: HTTP for Tiddlers. Here is the abstract:

TiddlyWeb was created as a web-based storage system for TiddlyWiki, a single-user all-in-one-HTML-file wiki. TiddlyWeb answers the question: Using what we know about the open web, and especially HTTP, how would a system that supports multiple users and sharing of TiddlyWiki content be designed and built? The answer leads to a resource oriented design. TiddlyWeb builds on learning from previous systems. Its design and implementation illuminates useful patterns in service development and highlights common wisdom in systems design. Though sometimes described as a RESTful store for tiddlers, it is perhaps more appropriate to call it an HTTP store. Rather than going into detail on the architecture of TiddlyWeb, this paper reflects on the lessons learned during development.

My apologies for it being a PDF. Despite being a web oriented conference, the normal ACM rules apply: follow the template, submit as PDF. This results in an inaccessible document fraught with problems that others have explained in more detail.

Overall the process has been very positive. I enjoyed writing the paper, it crystallized many thoughts that were laying about latent in my brain, and it’s always nice to get some well thought out feedback.

I woke up Friday thinking “I ought to work on the TiddlyWeb documentation”. Then I thought “I hate editing in a web browser I want my vim”.

Similar thoughts happened a few years ago at Socialtext resulting in a few half assed attempts to use Perl or bash plus the REST API to GET some stuff into $EDITOR and then PUT it back. Over time the client-side libraries improved and one fine weekend Luke Closs created wikrad, a terminal-based browser and editor for Socialtext workspaces.

I don’t know if this is still true, but back when I was still there, wikrad completely revolutionized how the Socialtext developers used their various wikis. Instead of the tediously slow interactivity of the web plus the tediously noisy and also slow interactivity of a GUI browser here was nippy little wikirad making editing a relative dream. Gardening of the wikis skyrocketed.

So Friday morning I decided “I’m going twist wikrad to work with TiddlyWeb. It’s all just HTTP, should be easy.”

And indeed it was. Although my initial hopes to create a server-agnostic adaptation layer were a little premature, I was able to hack and slash at the code until a new thing was born: twikrad.

I’ve started using it today to get back to the original documentation task, thinking a bit about future development of TiddlyWeb. I must say, it’s splendid. Doesn’t do much, but what it does it does just fine.

As is often the case when I start doing any significant editing in a wiki, I find myself thinking about wikitext, especially the syntax thereof. Some people care about wikitext, others don’t. I find that those that don’t usually think of it is as a way to quickly create something that will be presented as HTML. I don’t think of it that way. Wikitext is a writing tool optimized for creating two things: connections and voids. The connections reify understandings shared by the person or people using the text. The voids show what is not yet understood but may need to be.

When thinking about wikitext in those terms a couple things become more clear:

• Vertical whitespace is a useful aspect of readability. Syntaxes which work against readability of the source wikitext are working against quality writing.
• Free links and their associated syntactic cruft are a barrier both to good writing and to creating connections and voids. More on this in an old blog posting.

The TiddlyWeb documentation is maintained, for hopefully obvious reasons, in the TiddlyWiki syntax. I don’t really like it. Interestingly much of the problem is not with the syntax itself (although it does have one of the noisiest free link syntaxes around) but with the techniques one uses to overcome the apparent flaws in the standard rendering to HTML.

Which is really just to say that the form of writing matters to what gets written and I’m glad I’ve got a tool that lets me play with that.

When one works in software development, like I do, and one does not work in frequent contact with clients and colleagues, like I do, it is very easy to lose track of the real world value of the work that one does. Instead it is easy to get caught up in the technical details of the work, especially the mistakes, the shortcomings and the imperfections.

Yesterday I went in to London to go to the official launch of the new website of the International Lesbian, Gay, Bisexual, Trans and Intersex Association at http://ilga.org/. It was a multi-hour affair with moving speeches from representatives from around the world talking about the importance of awareness, sharing experiences and making contact with a community.

The website was built through a partnership between BT and ILGA. Rather than BT giving ILGA a pile of cash they did something I think much more valuable: They gave time and expertise. That took the form of developers from Osmosoft who worked on developing and refining the website for about eighteen months. That built a relationship between those developers and the people and issues from ILGA. Relationships can be transformative.

I was not directly involved in the ILGA project (except at the very beginning when doing proofs of concepts) but it is built on TiddlyWeb so I provided a supporting role. I went along yesterday mostly as a gesture of continuing that support. What I got instead was a very strong reminder that the technical details of the work, especially the mistakes, the shortcomings and the imperfections are minor concerns in the grand scheme of things. TiddlyWeb has its flaws and frustrations, the additional ilga code is a fair amount of bubble gum and bailing wire. But that doesn’t matter.

What matters is the impact of the work. Without much marketing, the new website is already drawing many hits and comments from around the world. And right on the front page is a map that makes it very clear that just because you love your lover several repressive regimes in this, the 21st Century, claim the right to kill you.

Rafe Colburn’s Extreme agility is getting a lot of reads, especially Ryan’s comment. I’ve heard a lot of “How can we be more like that?” and “We’re sort of like that, but how come we don’t get anything done?” reactions.

In my former life as the other founder of Blue Oxen Associates I did a lot of thinking about effective collaboration. Blue Oxen’s work lead to a succinct definition of collaboration:

Collaboration occurs when groups of two or more people interact and exchange knowledge in pursuit of a shared, collective, bounded goal.

Collaboration happens all the time, but there is a big difference between simply collaborating and collaborating well. A team that is able to be effective with extreme agility is clearly doing some effective collaboration. So what’s the trick? Why can’t we all have that?

The guys that work on GitHub have chosen to do the work they are doing. This is the single most important factor in effective collaboration (There’s probably an entire book somewhere in support of that statement). Beyond that important choice, the developers have a greater chance of success by having a clear overarching goal that encapsulates lots of smaller, actionable goals. I don’t know what the goal is, but I can guess it is something like: “Make GitHub Awesome!”. The github guys can talk purposefully about this goal because they have the language that allows them to talk about it in a way that makes sense to them. This language is important both before the goal is fully formed as well as when breaking the big goal down into little goals and tasks. If the language is shared well enough, the tasks don’t need to be made explicit in todo lists, task cards or whatever, they simply fall out naturally from shared understanding.

In general terms:

• Collaboration is SharedAction.
• SharedAction is the result of a SharedGoal.
• A SharedGoal emerges from SharedUnderstanding and SharedLanguage.

If you find yourself in what’s supposed to be a team but it doesn’t seem to be gaining any collaborative synchronicities you might ask yourself if you really know what your goal is. If you can’t articulate that goal, take a step back and see if you can build some understanding amongst the group. Not about the immediate tasks, but the goal. If you find that you can’t talk about that because you don’t have the language, then step back again. You may find that you have to take a lot of steps, but until you have the language, effort spent on what you assume are the goals is potentially wasted.

Been a while since a posting about the state of TiddlyWeb. That’s because quite a lot has been happening.

Tiddlyweb 1.0 - Mid January TiddlyWeb 1.0 was released. The release freezes the HTTP and Python APIs at a known steady state. A 1.0.x branch of development will provide bug fixes as required. New features, optimizations, complex refactorings and other radicality will happen with a 1.1.x track. There are no immediate plans for that track, instead most development energy will focus on TiddlyWebWiki, which provides the platform for hosting TiddlyWiki content in TiddlyWeb.

TiddlyHoster - Development started late last year on TiddlyHoster an aggregation of content and plugins for providing a shared hosting service for tiddlywikis and other tiddly-content. It started out as a prototype but mostly works, so I guess it can be called a thing. If you have an OpenID (version 1.x at the moment) you can try it at http://hoster.peermore.com/

TiddlySpace - The gang at Osmososft have started design work on a thing called TiddlySpace which builds on the ideas in TiddlyHoster to create a workgroup oriented collaboration platform using TiddlyWeb and TiddlyWiki. The google groups thread gives a bit of information on the distinctions between the two.

Plugins Galore - The number of stable and usable plugins for TiddlyWeb has grown rapidly. The list on PyPI is getting quite long. Especially relevant plugins get their own repos on tiddlyweb’s github.

And beyond all that, there’s the usual experimenting, exploring, discovering.

In the previous posting I showed how to get TiddlyWeb working with Google App Engine but left things a bit hanging: There was no easy way to get some initial content bootstrapped into the hosted TiddlyWeb. It is possible to do direct HTTP calls to the server, using something like curl, but that can be a bit cumbersome. Another option is to use tiddlywebweb, I’ll describe that method here.

tiddlywebweb was first mentioned on this blog in a posting that described how to make a store for TiddlyWeb and ranted a bit about how useful a well described and nicely constrained HTTP API can be. tiddlywebweb uses the TiddlyWeb HTTP API to store and retrieve content to and from a remote TiddlyWeb server. Talking to a TiddlyWeb server is exactly what we need to solve our app engine problem, so let’s do it.

If you’ve followed the instructions in the previous posting you have, running in your local app engine SDK, a TiddlyWeb server at http://localhost:8080/. If you go that URL you’ll see there are links for bags and recipes, but no bags and recipes to be found, and no tiddlers. Leave the server running. In a terminal window do the following:

mkdir gaeproxy
cd gaeproxy
sudo pip install -U tiddlywebplugins.tiddlywebweb

If you don’t want to install all the dependencies (because you already have them) you can add a --no-deps after the -U. If you prefer to work with a virtualenv, go for it, the goals here are:

• Make a directory in which we will create a tiddlyweb instance.
• Install tiddlywebplugins.tiddlywebweb.

Once the install is done, we need to create, in the gaeproxy directory, a tiddlywebconfig.py file with the following contents:

config = {
    'log_level': 'DEBUG',
    'server_store': ['tiddlywebplugins.tiddlywebweb', {
        'server_base': 'http://localhost:8080',
    }],
    'system_plugins': ['tiddlywebwiki'],
    'twanager_plugins': ['tiddlywebwiki'],
}

You can then run a command to confirm a) that things aren’t going to blow up 2. that there’s nothing in the store:

twanager lbags

This should return nothing but also report no errors. If you get errors you’ll want to confirm that your configuration is correct, you have the required modules installed, and your app engine application is running.

Once you’ve confirmed there’s nothing in the store, we can put some stuff in there:

twanager bag system </dev/null
twanager bag common </dev/null
twanager bag console </dev/null
echo $'/bags/system/tiddlers\n/bags/common/tiddlers' | \
    twanager recipe default
twanager update

Those commands create two bags, system and common, create a recipe using those bags and then update the contents of the bags with tiddlers provided by the tiddlywebwiki plugin.

Now go to app engine TiddlyWeb at http://localhost:8080/recipes/default/tiddlers.wiki and see if you have a wiki.

Another useful command that works over tiddlywebweb is imwiki. If you have a TiddlyWiki you’d like to import into your app engine setup, go to your gaeproxy directory, and twanager imwiki common < mywikifile.html.

So there’s the basics of using tiddlywebweb with a TiddlyWeb hosted on google app engine. If you’ve deployed your application to Google’s appspot, update the tiddlywebconfig.py in the gaeproxy directory so that server_base points to the appspot domain instead of localhost.

There are some limitations with this approach:

• User entities are not exposed over the TiddlyWeb HTTP API, so twanager commands for manipulating users (lusers, adduser, addrole, userpass) will not work. In the app engine setting this doesn’t really matter as Google users are used, not TiddlyWeb users.
• If you’re not familiar with directly manipulating tiddlywebconfig.py and TiddlyWeb instances, this process may be rather opaque. FND has done some experimenting with creating instances that take out some of the steps. Perhaps he will post the details.

This combination of stuff has so many little happy web bits.

It’s been possible to run TiddlyWeb on Google App Engine for more than a year now, but the process to get things started and keep code up to date has been cumbersome. Recent changes to how TiddlyWeb is packaged and deployed have made the process a good deal easier. Assuming you can satisfy the following requirements

• Google App Engine SDK
• pip
• virtualenv
• git
• Some version of make

then here is the process to get a basic working app:

git clone git://github.com/tiddlyweb/tiddlyweb-plugins.git 
cd tiddlyweb-plugins/googleappengine
make go

After that process completes, in the subdirectory called go will be a working app engine application of tiddlywebwiki. You can host with you local SDK appengine launcher or toolset and visit it at http://0.0.0.0:8080/. If you want to deploy it to appspot.com you will need to:

• Edit app.yaml to change the name of the application.
• Edit tiddlywebconfig.py to change the host in the non-dev server_host configuration item.

What make go does is install all the necessary requirements into a virtualenv and then symlink them into an app engine directory.

So now what? Now you have a TiddlyWeb setup with no content and no clear way to add content. Either read the README in the tiddlyweb-plugins/googleappengine directory, or wait for my next blog post.

I’ve created a plugin for TiddlyWeb that provides a very simple wiki that adheres to some old school wiki ways, including links to other pages being CamelCase, the editor being a simple textarea, and RecentChanges being provided with the same link-space as the “normal” pages. It uses markdown as its syntax, with the addition of WikiLinks.

You can get it as tiddlywebplugins.simplewiki from PyPI. The PyPI page includes installation information. The code is on github.

You can see a running version at http://simplewiki.peermore.com/wiki Feel free to play around there.

I made it as a demonstration showing how to create a particular type of application with TiddlyWeb and tiddlyweb plugins. We’ve identified a few different application types in the TiddlyWeb universe:

• Those that exercise its identity as a server-side for TiddlyWiki.
• Those that exercise its identity as a headless RESTful document store.
• Those that use it as building blocks for web apps.

Simplewiki is the latter. It is a rather small amount of code that assembles other TiddlyWeb plugins as Python dependencies and packages them with an install script and the small amount of data required to get things rolling.

Note that though there have been calls for a canonical TiddlyWeb application, I don’t think this can be called one, because it only covers one aspect of TiddlyWeb application creation, and the easy aspect at that. However it is probably a useful base case for all types.

It’s probably most informative to go look at the code but the following provides an overview of how things are put together.

tiddlywebplugins.simplewiki, the Python package, started life as a copy of the pluginmaker, which provides basic fill in the blank templates for starting a TiddlyWeb plugin project. Once those blank are filled in, it is a matter of adding functionality and the pieces to support that functionality.

All of the output from SimpleWiki is HTML, so it uses the do_html decorator from tiddlywebplugins.utils to wrap web handlers with code that ensures HTML output. That output is generated from templates which are managed by the tiddlywebplugins.templates package. Fed into those templates is text that has been rendered to html by the tiddlywebplugins.markdown package.

The text comes from tiddlers stored in a configurable recipe which can optionally use bags that have policies constraining access to read, write and create the tiddlers. Tiddlers, recipes, bags, policies and authentication and authorization handling all come from core TiddlyWeb. The wiki URL route is mounted via a handler in the simplewiki plugin which adds to the routes table managed and presented by core TiddlyWeb.

To make it easy to create a new wiki, Simplewiki includes a script called simplewiki that gathers up data from the plugin and provides it to tiddlywebplugins.instancer. Instancer is described as “A TiddlyWeb plugin to simplify instance management for verticals.” This is exactly what it does. The simplewiki script runs, creating a new instance including a store with a default configuration and a recipe name “wiki” that refers to a bag named “wiki” that contains a tiddler named “FrontPage”. The bag and recipe information are contained in a python module (tiddlywebplugins.simplewiki.instance), and the tiddler is included as package data (i.e. a file contained in the package accessible by Python code). This instancer functionality is extremely powerful and will only get more so as it is improved with use.

If simplewiki is not used, the tiddlywebplugins.simplewiki may be added to any existing instance in the usual way: By adding it to ‘system_plugins’ in tiddlywebconfig.py. If that’s done then a recipe will need to be configured for the wiki to use as its data source.

So with just the basic package you get a simple functional wiki that can be configured to use access control if you like. Stop reading now if you don’t need more more than that.

But wait, there’s more!

Because the tiddlywebplugins.templates package is being used to manage templates, if a directory called templates is present in the instance, it will be checked first for templates before checking the package data. This means you can override the templates with your own, per instance.

You can add Atom feed support by installing the tiddlywebplugins.atom, and providing a link (via the templates) to the Atom feed of the recipe driving the wiki.

You can use recipe_templates to provide context dependent tiddlers in the recipe used to drive the wiki.

Simplewiki is a plugin, but is also pluggable itself. You can add PageName, function pairs to the SPECIAL_PAGES dictionary to add dynamic pages to the wiki (this is how RecentChanges works).

Creating this plugin has been a good experience as it has helped point out both strengths and weaknesses in the TiddlyWeb core, other plugins and the instancer system. Those other pieces will improve as a result. Simplewiki’s own code is quite verbose, but with some refactoring, it could probably become very small. There’s a lot of what people like to call boilerplate (that I call transparency) that could be hoisted to utility modules. If this happens then plugins will become still more focussed on just being and showing what they do, not how they do it.