Wiki clusters are a set of Wiki installations distributed in different offices. This is for large corporations who have a need to work on content in the local offices without depending on the WAN (internet) speed. (Topic started in OfflineWiki)

• Pros:
  • LAN speed for collaboration.
• Cons/catch:
  • Setup issues: Web server and TWiki needs to be installed in each office.
  • Intelligent merge is necessary.
• How:
  • Synchronize constantly in the background.

Related: OfflineWiki, ReadOnlyOfflineWiki, ReadWriteOfflineWiki, WebsitePublishing, NonWebAccessToWiki, TWikiWithCVS, TWikiXML.

-- PeterThoeny - 23 May 2000

Of course the problem arise when there are slow links. I've thought about this and something based on automated email processing with real-person (editor/maintainer) signalinng when conflicts arises might work.

Of course the trick is to reduce the amount of sync conflicts that occur.

-- NicholasLee - 23 May 2000

At work we are considering to do a one way synchronization of selected webs between sites using rdist. I.e:

Site A: (main site)		Site B: (satellite)
twiki/data/Main	==>	twiki/data/Main
twiki/pub/Main	==>	twiki/pub/Main
twiki/data/TWiki	==>	twiki/data/TWiki
twiki/pub/TWiki	==>	twiki/pub/TWiki
twiki/data/Web1	==>	twiki/data/Web1
twiki/pub/Web1	==>	twiki/pub/Web1
twiki/data/Web2	<==	twiki/data/Web2
twiki/pub/Web2	<==	twiki/pub/Web2

Webs can only be edited at the site where the synchronization is originating from. This can be controlled by the template directories. Restricting edits to one site only is a tradeoff between two-way sync issues and usability. Registration needs to be done only once, at Site A.

-- PeterThoeny - 09 Mar 2001

Ugh... With better DataAndCodeSeparation syncing all the webs on X locations, including the templates specific to those webs & the attachments is as simple as syncing just the webs directory as posited on the page above, rather than faffing about with individual sub directorys. For example, the above description misses the possibility that Web1 & Web2 can have different templates, which means you have to sync a subdirectory of a static directory across systems as well. It also misses the possibility that the two sites may also have different local plugins in use. Assuming they do, you therefore need to expand the above diagram to:

Site A: (main site)		Site B: (satellite)
twiki/data/Main	==>	twiki/data/Main
twiki/pub/Main	==>	twiki/pub/Main
twiki/templates/Main	==>	twiki/data/Main
twiki/bin/TWiki/Plugins/???	==>	twiki/pub/Main
twiki/data/TWiki	==>	twiki/data/TWiki
twiki/pub/TWiki	==>	twiki/pub/TWiki
twiki/templates/TWiki	==>	twiki/templates/TWiki
twiki/bin/TWiki/Plugins/???	==>	twiki/bin/TWiki/Plugins/???
twiki/data/Web1	==>	twiki/data/Web1
twiki/pub/Web1	==>	twiki/pub/Web1
twiki/templates/Web1	==>	twiki/templates/Web1
twiki/bin/TWiki/Plugins/???	==>	bin/TWiki/Plugins/???
twiki/data/Web2	<==	twiki/data/Web2
twiki/pub/Web2	<==	twiki/pub/Web2
twiki/templates/Web2	<==	twiki/templates/Web2
twiki/bin/TWiki/Plugins/???	<==	bin/TWiki/Plugins/???

NB, the ??? means that the above schema doesn't really allow for plugins to differ at the two sites - even though they can be activated/deactivated at the web level.

Contrast this with:

Site A: (main site)		Site B: (satellite)
twiki/webs/Main	==>	twiki/webs/Main
twiki/webs/TWiki	==>	twiki/webs/TWiki
twiki/webs/Web1	==>	twiki/webs/Web1
twiki/webs/Web2	<==	twiki/webs/Web2

As I said, I regularly sync for ReadWriteOfflineWiki access between my (linux) laptop & (linux) desktop, and the /webs/stuff relevent to a web, and not code vs having lots of directories to sync is a god send. For low bandwidth situations, rsync is a good solution - and even allows syncing of large sites over even a simple dialup link. (And in the rsync case, having the single mount point simplifies the sync since you're not forced to take someone else's code (and hence their config) just to sync data)

For two way editting if both sites work from a central CVS repository syncing occasionally, and having a small team of people responsible for content looking into things, you gain alot...

-- TWikiGuest - 11 Mar 2001

Personally having partially shoehoned TWiki into CVS a while back and coming up against some limitations of CVS vs TWiki's usage of CVS, I'm not sure its a good idea to create a dependancy on CVS for clustering.

Two things:

i) It shouldn't be hard to build the lazy commit/conflict/resolve cycle that CVS has for TWiki over RCS. In fact the method I'm thinking off which is a modification of how I got TWiki to work with CVS will help other areas of TWiki as well. Like the hidden form field from the preview to save scripts.

ii) Once the same mechanism is in place, if a predefined primary it should be too hard to get two TWiki sites (not a Cluster, more Mirrors) to sync with each other via LWP. Could even extend this to version locking that probably would work well on a LAN.

None of this requires CVS. In fact I've been thinking it might be better to try something like Xdelta as the version management subsystem as it might deal with binaries in a better manner.

-- NicholasLee - 11 Mar 2001