Candidate: RecommendedStorageOfPluginData

Peter wrote a nice lump of code that he recommended people duplicate into their plugins. As it is ostensibly the same for all plugins it would be better served as a piece of SharedCode, and parameterised as necessary.

• added to CandidateSharedCode by MattWilkie - 22 Jun 2004

How would you include it? As a new module (e.g. PluginData.pm )? I'd be keen to make the interface a bit more abstract (I still cling to the hope that some day we'll be able to refactor into a database). This could be achieved by manipulating file handles rather than file names.

-- CrawfordCurrie - 16 May 2004

Well, its part of the Plugins interface, but as we are stuck with the flat functional interface it'd best go in FuncDotPm or in the oft-thoughtabout Plugins superclass.

-- MartinCleaver - 16 May 2004

Err. I just installed this on my Cairo box. I note it includes the CairoCompatibilityModule? . Is this going to break my Cairo install? CC, will CCM disable itself if installed on a too late a version?

-- MartinCleaver - 18 May 2004

It should not break your Cairo install - I use it in Cairo all the time. It's only enabled if $TWiki::Plugins::VERSION < 1.020. You may see redefinition warnings in error_log if it is enabled, and you are using code between Beijing and Cairo, but they can be ignored.

-- CrawfordCurrie - 18 May 2004

I am concerned that shared Plugin code raises the complexity of the Plugins in regards to dependencies, installation and comprehension. In the spirit of KISS I'd rather see quality patches to enhance the FuncDotPm with commonly used functions. That way we can keep the simply way of copy and play installation.

-- PeterThoeny - 20 May 2004

Agreed, it does, and it would be great if we could release all the shared code that way. However, SharedCode does something that patching FuncDotPm cannot, and that is to offer the CairoCompatibilityModule? . This module lets Athens and Beijing users use plugins that have been coded to target Cairo. This means that plugins authors don't have to carry compatibility baggage in their plugins, and don't have to build separate releases for pre-Cairo versus Cairo TWiki.

SharedCode also incorporates functionality that is shared among plugins, but has previously been rejected for inclusion in the core (Attrs.pm).

BTW "copy and play" is still there, it's just that you have to copy SharedCode as well as your plugin.

-- CrawfordCurrie - 20 May 2004

Moved from the support web

Crawford: A Plugin can be coded conditionally so that it runs on older and newer TWiki versions without any additional code dependencies (like on SharedCode). This applies to Plugins that changed inofficial TWiki calls to the evolving official TWiki::Func calls. Here is an example from the InterwikiPlugin that initialized variables conditionally:

if( $TWiki::Plugins::VERSION >= 1.020 ) {
    $upperAlpha    = TWiki::Func::getRegularExpression("upperAlpha");
    $mixedAlphaNum = TWiki::Func::getRegularExpression("mixedAlphaNum");
} else {
    $upperAlpha    = $TWiki::upperAlpha;
    $mixedAlphaNum = $TWiki::mixedAlphaNum;
}

The same can be done for function calls. Untested example:

my $date = 0;
if( $TWiki::Plugins::VERSION >= 1.020 ) {
    $date = formatTime( time(), "\$day \$month \$year", "gmtime" );
} else {
    $date = TWiki::getGmDate();
}

-- PeterThoeny - 22 May 2004

Of course it can. I am perfectly familiar with this technique, it's just one of several options I considered.

The very reason the CairoCompatibilityModule? exists in SharedCode is to protect plugins authors from having to know the gory details of the TWiki internals, and protect them from having to write such conditionals. The goal is that plugin authors can write code against Cairo that will still work against Beijing without having to be explicitly tested in that environment. If you use conditionals then the plugin author has to test against all prior releases of TWiki. For most plugins, that simply won't happen. It is better to write a compatibility module once and be done with it - that way, only one person has to decode the undocumented changes to the core.

BTW the ActionTrackerPlugin depends on SharedCode independently of the CairoCompatibilityModule? , as it uses code shared among several plugins. There are other shared code opportunities that haven't been leveraged yet, that will increase the dependency. I don't like dependencies any more than you do, but I like code duplication a whole lot less. At some point we have to bite the bullet and accept that dependencies will exist, do exist, and stop ignoring them. Dependencies already exist independently of SharedCode - several plugins depend on, for example, EditTablePlugin.

-- CrawfordCurrie - 23 May 2004

I am playing the devils advocate here

One would expect that authors who use undocumented calls could clean up after themselves by using conditional code so that the Plugin works with any TWiki release.

With shared code dependencies we might get into "DLL hell" issues after some time (you need version X of shared code to use Plugin Y of version N, but this breaks Plugin Z, etc), e.g. you loose the simple unzip and play way of installing/updating Plugins.

-- PeterThoeny - 25 May 2004

The unfortunate reality is that most plugins are not maintained, and any that use undocumented calls will continue to use undocumented calls, even after Cairo is released. AFAICT, you and I are the only regular maintainers of plugins. Most authors throw plugins over the fence and subsequently ignore them. If plugins authors do upgrade their plugins, they don't have to use the compatibility module. I haven't used it myself in some cases, preferring to use conditionals where the rest of SharedCode is not used. However the CairoCompatibilityModule? lowers the barrier for plugins authors to perform upgrades. Perhaps more importantly, it makes it easier for others to step in and perform them if - as is the general case - the plugin author is slow to respond or has simply gone AWOL.

It really comes down to what you believe is more likely to happen. Is it more likely that plugins authors will recode their plugins each time the core changes, or is it more likely that the SharedCode repository will be recoded to ensure the old plugins code still works?

BTW DLL hell is always a risk, yes, unless the authors of SharedCode are concious of the risk and actively undertake to ensure it doesn't happen. The goal is that the most recent version of SharedCode should always work with all prior official TWiki releases, however the TWiki core is coded. Note that if we had a decent installer this could be managed automatically.

-- CrawfordCurrie - 31 May 2004

The main SharedCode page should provide a prominent link to this discussion page.

-- MattWilkie - 22 Jun 2004