The Conceptual Underpinnings of JotSpot

Jon Udell a couple weeks ago blogged about JotSpot. JotSpot is being billed as "Wiki as a Developer platform". My immediate impression was that I've seen something like this before, remember Fitnesse?

The idea of a Wiki is pretty simplistic. A Wiki allows convenient editing of a web page by anyone. In the old days, to edit a page, you had to write some HTML and upload it to an location that was accessible by the Web Server. Years ago it was extremely innovative, however today, almost any CMS or Blog software has this same capability. So how then does a Wiki form the basis of a paradigm shifting way of developing applications?

That question intrigued me. There are two subtle features of Wikis that I find extremely compelling. The first feature is that every page is versioned. Versioning is the mechanism that Wiki's use to enforce "Soft Security". However, versioning is extremely useful even if you don't share editing responsibilities. Just ask any Eclipse user who has use "Local History" as a mechanism for undo. Since all Wiki is just text, differencing the versions is simple.

The second interesting Wiki feature coincindentally enough also related to Eclipse. That is Refactoring. The Wiki that I use is ZWiki. I noticed that it has got two time saving refactoring like capabilities. The first is that when you rename a link, the corresponding Wiki page is also renamed. The second is that when you receive comments, the comments are embedded in the original Wiki text. This makes it easily refactor comments and move them to other locations.

What you begin to realize is that, by keeping content in textual form makes versioning and refactoring easier. This is in stark contrast to systems that start from a more structured perspective. Systems where everything is defined in objects with well defined associations between them. The objectified form does not afford the same level of flexibility and maleability as the textual form.

There are several approaches to specifying code, code can be as text, an algebraic datatype or as a quasi-quote. The segue from Wiki to Development Platform is the employment of Quasi-quotes. Quasi-quotes have been used before in the form of HyperCard. JotSpot takes it to the web leveraging ideas from Wikis.

However, you have to have more than "code embedded in data" to get to a paradigm shift. The second evolutionary step towards this is realizing that the page itself (now indiscernable from code) can also act as an Active Object. That is, a page now serves a collector and aggregator of information. With JotSpot you can send email to a page, you can also have the page pull information from other web sources. The Wiki page now has channels for receiving and sending. Active Objects or Agents have been around for a long time, however the advantages of merging the UI with an Active Object may have not been noticed.

Now that a Wiki page is an aggregation mechanism and pages themselves are data, you immediately see the Composite Pattern at play. Allow pages and their meta data to be queryable and you see the beginning of a mechanism to aggregate information. The evolution of Wikis to Blogs was that blogs allowed entries to be arranged and queries in a chronological sequence. Allowing arbitrary queries opens up the opportunity for a wider variety of uses.

JotSpot has merged UI, Code, Data, Communication and Queries all into a single Wiki page. This appears to be a complete violation of our architectural instincts for modularity. Is this a good thing or a recipe for complete chaos? The answer to this quandry is that sometimes simplicity outweighs any need for structure. However, the moment you start melding concerns that should be separable and allowing unfettered computation, you arrive at a manageability and scalability problem.

Recently there have been a attempts to simplifying web development. The solution however may just be within our grasp, that's exactly what JotSpot is hinting at. On the otherhand, for JotSpot to be a viable business, they have to come up with a scalable solution for thousands of developers. This problem isn't much of a problem if a developer controlled his own box. So let's say we had to design a Java Web framework based on the ideas found in JotSpot. How would we start?

P.S. Did anyone hear that "Prevayler" was mentioned as the persistence mechanism behind JotSpot?