Peer Pressure

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.