create new tag
, view all tags

View.pm is littered with support for Mirrors - no one uses them

A stated goal of DakarRelease is performance. As part of the rationalisation efforts I suggest we remove all remnants of the mirror code.

  • AFAICT, No one uses it.
    • 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

Quick Poll

5 AntonAylward 29 Oct 2004  
5 JohnCavanaugh 16 Oct 2004
1 ThomasWeigert 05 Oct 2004
5 AntonAylward 05 Oct 2004
1 PeterThoeny 05 Oct 2004
4 CrawfordCurrie 02 Oct 2004
4 RafaelAlvarez 02 Oct 2004
5 SteffenPoulsen 02 Oct 2004
5 MartinCleaver 02 Oct 2004
Should we remove the mirror code?
Do you agree or disagree? Please select one of the radio buttons below and click the button.
I 1 - Strongly disagree   2 - Disagree   3 - am Neutral   4 - Agree   5 - Strongly Agree  

-- MartinCleaver - 02 Oct 2004


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

I would use mirroring ability if it was there and functioning, specifically for ReadWriteOfflineWiki. I don't care if it were as a core, plugin or an addon.

-- MattWilkie - 02 Oct 2004

I put that code in for use at work. It is tested and works. However we never rolled it out into production because the site that had an issue of a small pipe got a bigger pipe.

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.

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.

We probably need something like this in the near future, so I would not like to see this functionality removed.

-- PeterThoeny - 05 Oct 2004

Peter, would you mind providing some instructions on how to use this feature. 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

Thomas, the code is just for the UI to make sure that the edit and attach links point to the correct site, depending if the current web is a master or slave on the current site. There are some additional messages for the user (not checked in)

The actual sync is a separate process. Each site's master webs are sync'ed to participating sites with an rsync.

-- PeterThoeny - 14 Oct 2004

Summary: MirrorSupport is required. the current codebase will remain in place until a viable alternative implementation is available and officially blessed. requirements and implementation discussion refactored to RefactorMirrorSupport

-- WillNorris - 08 Oct 2004

I still invite others to vote.

I personally don't see why "someday maybe" is a good reason to keep seldom used and barely tested code in the most heavily trafficked part of the code.

I appreciate that Peter has a long queue of other tasks to handle. I would be surprised if defending mirrors makes his priority list.

-- MartinCleaver - 13 Oct 2004

Trivia question. What is the cost of calling one function in view that does this, with an empty $siteWebTopicName by default:

sub readOnlyMirrorWeb
    my( $theWeb ) = @_;

    my @mirrorInfo = ( "", "", "", "" );
    if( $siteWebTopicName ) {
        # code not shown here since not covered by default
    return @mirrorInfo;

We can remove the code if you bring a working alternative smile

-- PeterThoeny - 14 Oct 2004

If its not working or isnt complete, yank it out until someone has a desire to reimplement it as a plugin.

-- JohnCavanaugh - 16 Oct 2004

even if it works, the core code is aleady too big, and its not used by the core funtionality, so therefore it should be in a plugin. we need to simplify the TWikiKernel to have as little functionality & code as is needed for it to be TWiki. For everything else, we should make an effort to push it into a plugin.

-- SvenDowideit - 17 Oct 2004

I agree with simplifying the core code - as with the TOC plugin perhaps, it could be delivered as an 'always installed' plugin ('standard plugin'?), though in the case of mirroring it should probably not be installed by default.

-- RichardDonkin - 29 Oct 2004

Edit | Attach | Watch | Print version | History: r32 < r31 < r30 < r29 < r28 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r32 - 2004-10-30 - WillNorris
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.