Feature Proposals » Web specific working dir

Motivation

Some plug-ins have permanent data, which is subject to mirroring (ReadOnlyAndMirrorWebs). {WorkingDir} is not subject to mirroring, so we need to have web specific working directories.

Description and Documentation

TWiki::Store::getWorkArea($this, $key), TWiki::Func::getWorkArea($key), and other similar functions will have one more optional argument $web. If $web is provided, $TWiki::cfg{PubDir}/$web/work_areas/$key is returned instead of {WorkingDir}/work_areas/$key.

If $web does not exist, an exception is thrown in the same manner as other exceptional situations. If the corresponding directory does not exist, it's created.

The $web argument can either be a top level web or a subweb.

If a plug-in provides a feature in a site-wide manner (e.g. TagMePlugin - only one site-wide tag name space), it should not use a web specific working area.

On the other hand, if you enhance TagMePlugin so that it can split tag name spaces per top level web, when the tag name space splitting is in effect, the top level web name is supplied by TWiki::Func::getWorkArea($key, $topLevelWeb). If you split tag name spaces, there is no way to provide site-wide tag cloud.

Some plug-ins may need a work area even for a subweb. In that case, the entire subweb name is handed to TWiki::Func::getWorkArea().

Examples

Impact

Implementation

-- Contributors: HideyoImazu - 2012-11-22

Discussion

Overall, I think it is good to add an optional second parameter for the web name for web-specific plugin data.

A few comments:

• I'm unclear what the directory structure is for plugin working data, such as $TWiki::cfg{PubDir}/$web/working/FooPlugin/Main for Main web of FooPlugin?
• I'm unclear if sub-webs are supported or not.
• I'm unclear how a plugin can traverse the webs. For example the TagMePlugin needs to get all web's data to build a tag cloud.
• How are rename/move of topics handled? Plugin responsibility, or TWiki system responsibility? It looks like with proposal it can only be Plugin responsibility.
• Using the pub dir for plugin working data has some disadvantages:
  • It exposes the working area data to the world.
  • It raises the complexity because working data is now in two locations, not simply one dir with sub-dirs.
  • It complicates backup and restore.
• Mirroring is a special case. I suggest to have:
  • either: All working data below the plugin's working directory (e.g. a /webs/ sub-directory for web specific data), and make the mirror logic aware of the working data locations,
  • or: Have web specific working data under pub if site mirroring is enabled, else store in /webs/ sub-directory of plugin working dir.

-- PeterThoeny - 2012-11-26

• I've described the exact behavior above. TWiki::Func::getWorkArea('FooPlugin', 'Main') returns $TWiki::cfg{PubDir}/Main/work_areas/FooPlugin. It's up to FooPlugin to decide how to use the directory. This enhancement doesn't provide more or less.
• Subwebs are supported but there are cases where only top level webs are handed to TWiki::Func::getWorkArea(). This is now mentioned above.
• If TagMePlugin uses web specific work areas for tag name space splitting, there is no need to traverse multiple directories.
• I don't know if there are plug-ins/add-ons using a work area and takes care of work area files when a topic is renamed or moved. It's up to the plug-in. Regardless a plug-in uses the site-wide work areas or web specific work areas, it's up to the plug-in to deal with topic rename and move.
• I agree using the pub directory for plug-in work areas has a disadvantages - it makes work areas accessible to everybody as you said. But that's the only disadvantages, I understand.
  • I don't think added complexity is a disadvantage per se. If you provide additional feature, you need to add complexity in once place or another. There is no free lunch.
  • I don't think it complicates backup and restore. In a site backup or a web backup, the entire pub directory or the pub directory of the web is backed up. It doesn't exclude pub/WEB/work_areas.
• Practically speaking, I don't see merits in {WorkingDir}/work_areas/webs/WEB/PLUGIN because that directory becomes orphan when the web is renamed/moved. Web rename/move don't take work areas into account now. There is no plug-in handler for web move. pub/WEB/work_areas is moved automatically (!?) when WEB is renamed/moved.

-- HideyoImazu - 2012-11-27