Wiki with offline functionality - targeting mobile users
Mobility is getting a lot of attention. Intel's Mobilized Software Initiative is an interesting big step in this direction. Applications written for mobile devices have characteristics very different from usual applications. For e.g. they should primarily assume that connection is available occassionally. They should also adapt themselves to change in form factor and other changes experienced if an app were to hop from one mobile device to another.
Given this context, how should wiki systems support mobility? For once, weblogs are popular because one can write them in offline mode (say, on PDAs) and submit them by ftp when you have connection. You can also sync RSS feeds and local app can put an UI. But not so with wiki systems. In fact, this one factor actually makes email attractive because people always have access to required information even on laptops in remote, unconnected locations.
The key to offline usage is caching and automatic updates. Applications such as Plucker and AvantGo do this, but they are primarily read-only. Semantics for wiki systems should be different.
Here are some thoughts that I came up with. First part: Use IMAP backend for wiki systems.
And that means, IMAP provides interface for read as well as writes to topics. Since versioning of topics is important, store each successive version of a topic as new email (IMAP APPEND command). Some people raise concern of too much storage requierd. But we can easily automate management of older topic versions and entries. Email tools will allow you to archive them nicely. The file/DB storage is still required: It is used as cache. As it is, twiki already uses two files per topic: One ",v" file - versioned contents, and another: actual file as seen during edit. The first one is now replaced with IMAP backend (and appropriate RCS like interfaces). The second one will primarily be current contents (used for implementing search, for e.g.), and associated cache information (see below).
And second part: Make wiki completely local to user. This means, wiki will create one hierarchy for each user (assuming that user writes contents, or wants to cache specific, subscribed pages). So wiki installation on server will primarily be published "read-only" content + user specific cache folders. On laptops, the user cache contents are replicated as is.
So, why is this useful? Because it gives ample opportunity for implementing Dynamic functions on Cache. This is new architecture that is being talked about (for e.g. Adam Bosworth's weblog). You require control over cached content in a way you can do some local activity there. For example, if you have cached contents of a table, then you should be able to sort locally on laptop.
The most interesting part: Wiki systems already provide the specification of this functionality. Its topics are mix of static and dynamic content specifications. For e.g. %DBQUERY{host=xxx query="SELECT ..."}% or %INCLUDE{http://www.google.com/}% primarily execute as dynamic queries. (The notation is specific to twiki, DB query is for example only.)
And then, some of the wiki systems also provide caching layer. If two users click on topic with contents such as above, the caching will happen and the second page is returned from cache.
But we require more control over caching. For one, I would like cache to be part of query, and not part of topic. This may mean adding of some metadata, associated with topic. Second, you require more specification - such as how often to cache, whether it has to navigate in remote website and cache everything. In some cases, it is heuristics: If web page has "Page 1" below, it should go ahead and cache that link as well.
When you do a SEARCH in twiki on a page which has INCLUDE, the search happens on dynamically included content; not on string "INCLUDE". This is important distinction. This is special to INCLUDE directive, but you require control over this aspect as well.
And then the last part is to allow users to modify the topics independently and use appropriate merging algorithms. Because of IMAP and email interface, we can send the changes by email. If auto-merge is not possible, conflict resolution screens can be processed after next sync.
In essence: I think wiki systems are already geared for mobility. With right integration, they can even help existing web sites to be experienced nicely in offline mode. If websites were to implement special web services, the wiki systems can easily incorporate them as plug-ins. And access control is already available and used in wiki designs.
What more can one ask for?
-Vinod
