View.pm is littered with support for Mirrors

• AFAICT, No one uses the current implementation
  • Its not documented
  • Its probably buggy
  • It'd be better in a plugin anyway
• It complicates the code
• It slows down the code for those who don't use it
• It slows down the code for those who do use it
• There appears to be a simple, generalised solution by just implementing and then customising changing the Web*ControlBars on the mirrored site.
• Its incomplete - at least, there is no documented way of pushing the changes to mirrors

The mirror feature was never documented, but to give you an idea:

• TWiki multisite installation where content can be viewed locally (high speed)
• Each TWiki's TWiki.cfg has a site name setting
• Edit is done on a local or remote TWiki, depending on a policy setting
• Each web has a master site, all user update to that web happens only on that server
• Content of that web is mirrored to all slave sites
• If you are in a web on a site where the web is set as master for the site, you see the same edit and attach links like in a regular TWiki
• Else, if the web is on a slave site, and you will see the edit link pointing to the master site

For example, the master site for the Main, TWiki and Engineering webs would be in corporate headquarters, the master for the Emea web would be in Paris, etc.

Discussion

What is mirror support?

-- ArthurClemens - 02 Oct 2004

Its a perhaps-never-used and certainly-undocumented feature that I assume allows certain wikis to act as read-only copies. It seems incomplete as there is no syncing tool and it is likely broken as nothing else knows about the concept of read-only, so comment, etc would not honour it.

See SVNget:/lib/TWiki/UI/View.pm - around line 167

-- MartinCleaver - 02 Oct 2004

Before I discovered mirroring in the core I wrote a package that published TWiki pages as indexed read-only web pages. This has since transmogrified into PublishAddOn. The point is that no core changes were required to do it.

I would personally not do writeoffline using the TWiki core code, but would use JavaScript and cache the changes.

-- CrawfordCurrie - 03 Oct 2004

This is a "low hanging fruit" way of supporting multisite installations where you get high speed for view, and where you do not need to worry about merge issues since each web has only one master site.

-- PeterThoeny - 05 Oct 2004

I would love to try it out. I looked at that code long time ago and got the impression that it was not finished. It is great to find out that it is actually working and tested (albeit I still have not found the synchronization feature). In my environment, having the ability to synchronize webs in a multisite manner would be a real benefit.

See also the references in "related topics" below...

-- ThomasWeigert - 05 Oct 2004

(in response to a comment that one should rely on well-tested plugins to achieve mirroring rather than adding this functionality to core) As far as I know, there is no "well-tested plugin" which provides the mirroring capability. By "mirroring" I mean that you have a full-fledged Wiki at several sites such that a topic is edited only on one site, but the topics can be viewed locally. This need has been periodically surfaced, see also the attached "related topics" references. Using an approach of publishing the wiki site at the remote is a rather weak way of mirroring a web.

-- ThomasWeigert - 05 Oct 2004

I'm going to try to set up mirroring as follows:

• I have a redundant global web service implemented on several servers
• I would select one server as the master
• there would be a plugin that keys off save events and starts a sync to the other servers from the master.
• on the slaves, binaries that would perform writes to the data get redirected to the master. So view, viewauth, rdiff, rdiffauth, viewfile and changes would run on the slaves.

Things I would need to figure out:

• what event handler can I use so all topic save/move/attachings trigger a sync
• how to tell apache to redirect the writing binaries to the master
• decide wether to use synchronous or asynchronous pushes of updates from the master to the slaves

Is there any reason why this would not work?

-- WoutMertens - 30 Nov 2006

Object-oriented Implementation

Have a configurable "write dispatch" table. The write operation depends on the web. Actually all of Store.pm shoudl be so vectored. It makes the code perfectly geenral.

I long ago outlined a model I experimented with in DataAndCodeSeparation, heirachical webs in LogicallyNestedWebs, and others.

The idea is that the table says the method (file system, ftp, http ..), the location and a few parameters.

Part of my motivation for this was better control over rvisions of attachements and access control. I wanted to be able to roll back the topic content without being forced to roll back the access vector and the contents of the forms. Similarly advacne or roll back the attachments independently of the topics. So my dispatch table was more like ..

Across first would look like this:

Down first would look like this:

The present Store.pm code is the "filesys/compatible" row of the first table.

-- AntonAylward - 05 Oct 2004

We're getting there, Anton. Store is already vectored, but it's not very smart (only one impl supported at a time, for example). But the first gap to bridge is to honour the encapsulation of the Store, which has been done in LocationLocationLocation.

-- CrawfordCurrie - 06 Oct 2004

Is it complete? AFAICT, there is no mechanism in TWiki to push the changes on the master site to the slaves.

Shared disk is one way but its fraught with problems when you scale to two way. An AfterTopicSaveHandler plus an AfterAttachmentSaveHandler could be a neat way to punt the changes to all mirror sites.

The transport could save-through (middleware|email|ftp) too; there are good reasons why TWiki should be in control on the recipient end: avoid writing directly to store.

-- MartinCleaver - 06 Oct 2004

Implementation using topics

If all that the mirror code does is to disable menus then much of this can be implemented with different WebTopControlBar and WebBottomControlBar (search for these in my comments on PatternSkinDev).

-- MartinCleaver - 06 Oct 2004

AFAICT all the current mirror code does is to disable stuff, yes. I guess the assumption is that you have an rcp or similar in the background (pull, not push).

-- CrawfordCurrie - 06 Oct 2004

If that is the case then everyone (even the people who do use mirror) loses by having extra logic in the code. The webs should be configured to statically replace the WebTopControlBar and WebBottomControlBar - it'll be quicker and cleaner for everyone.

-- MartinCleaver - 06 Oct 2004

The impact can be neglected since action is only taken if a $siteWebTopicName variable in TWiki.cfg is set, which is not the case by default. If taken, the action is to check for web preferences settings, read special templates and modify the edit and attach links.

-- PeterThoeny - 05 Oct 2004

refactored sections from DitchMirrorSupport -- WillNorris - 08 Oct 2004