ReadWriteOfflinePlugin enables roaming TWiki users

There have been a couple of attempts at building such a roaming technology into TWiki, but these have suffered the same flaw. They try to re-use third party synch tech, in the belief that it's easy to synch the database (the raw topic store). Unfortunately it's not so easy to synch the actual topics – histories, meta-data, attachments etc. Simply synching the topic files ends up with corrupt or lost histories, lost content, frustrated users. This article describes the ReadWriteOfflinePlugin which has been built by WikiRing engineers to address this problem.

The first problem is that synching topics is non-trivial. There are a couple of approaches you can take to this. The first is to treat a roaming machine as a client of the wiki server, and merge offline changes by rolling them forward into the server, then updating the client by copying what is on the server. This results in the roaming client being a mirror of the server. The second approach is to treat the roaming user as a peer of the server, acknowledging that the topics in the client may have different revision histories, and seeking just to merge the content of the topics. The first approach is appropriate in an environment where there is a single server sitting in the middle with lots of satellites. The second is more appropriate in a multisite environment, and allows the scenario where a laptop synchs webs from several servers, or even where multiple servers synch with eachother.

The ReadWriteOfflinePlugin uses the second approach, as it offers the most flexibility in how you configure your servers, and your roaming clients. The synching problem is actually quite similar to the problem faced when two users simultaneously edit the same topic. You have to choose how to merge the topics so that you lose as little information as possible. Thanks to previous work done by a WikiRing partner, TWiki supports asynchronous edits by multiple users, so we can leverage this tech. All we need to know is what version of the topic was last successfully synched, and we can merge together server and roamer changes to create a new, common topic version, without losing history information on either server or client.

Choosing the tech you use to synch the data is not trivial either. Most third party solutions use something like rsync, or a similar low-level copy program. These are generally fast, but often require special configuration on the server, such as opening ports.

However with a wiki, you have an advantage; you know that it's happy to serve HTTP, so the ReadWriteOfflinePlugin uses that protocol for the synch. It won't be as fast as rsync, but as long as you only synch the topics you know have changed, that shouldn't be too much of a problem. It requires no special setup, and as long as the plugin is installed on both server and client, it "just works". The synch uses special URLs defined by the plugin to maximize synch performance.

A final problem is deciding when to do the synch. Do you synch at every opportunity, or only when asked to? What triggers a synch?

At the moment ReadWriteOfflinePlugin has to be explicitly triggered, but plans are afoot to make a client detect automatically when a server it is synched to is available, and automatically synch when it sees changes. This requires sensing not just topic changes, but also sensing when the bandwidth of the connection is limited, because of course you don't want the synch to saturate your 100 baud dialup line!

An common question relates to security of the connection used to synch the server and client. A server really needs to support https: connections to make this secure. If it does, then ReadWriteOfflinePlugin can use it.

The ReadWriteOfflinePlugin is currently being tested by WikiRing partners and will shortly be available from the WikiRing Solutions Repository for downloading by subscribers.