Tags:
archive_me1Add my vote for this tag create new tag
, view all tags

Alternate Plugin Management

(Refactored from PluginsInstaller)

Does community have interest in this very different approach?

  • Each plugin is in a tree of its own - hopefully with version number as part of name so that multiple versions can simultaneously exist.
  • A special plugin will then:
    • Identify and Pool config parameters into central area. The users keep configurations in special topics, with template managed by this plugin.
    • provide access to .txt topics - essentially documentation.
    • Allows a clean mechanism to set allow specific plugins to be available in specific webs.
    • Detects dependencies among plugins.
    • Establishes rendering order.
    • Creates 2-3 patterns of use of plugins: macro plugins, which replace a single macro with text, action plugins which act on area and so on. Plugins are called with specific APIs rather than "do anything we want with this topic content" approach.

I am suggesting this approach because we need to give top priority to management and make it easy. makes management pretty simple. Keeps the source tree clean. Encourages standard usage (since the plugin call is through APIs).

-- VinodKulkarni - 15 Sep 2004

To be honest, Vinod, no, I don't, for the simple reason that it implies too many architectural changes to the core. You have to think about this problem from the perspective of how difficult it is to get changes in the core code. It's easy to make changes on the plugins side of the plugins API, but much, much harder on the core side.

-- CrawfordCurrie - 15 Sep 2004

Actually I was thinking on lines of special plugin (let us call it MasterPlugin) that does this - i.e. it itself loads these new type of plugins.

If we look at MoinMoin, it has very clear distinction between macros, actions and so on.

-- VinodKulkarni - 16 Sep 2004

Before I started to implement this installer, I was working in a TwikiPluginManager to enable/disable plugins. The current code (not in CVS) allows to enable/disable plugins globally without using the DISABLEPLUGIN/ENABLEPLUGIN preferences.

I can see Crawford point, because this really must be a change in the Core. Having a plugin that manages these kind of plugins puts another layer of indirection between TWiki and it's plugins, thus potentially decreasing performance. This because the MasterPlugin must dispatch the calls to the plugin hooks to all the registered plugins.

There are few ideas lurking in your proposal that I like:

  • Having a centralized place to configure plugins. That means, having a simgle page with all the plugin configurations.
  • Enable/Disable plugins at Web level using a nice interface (DISBLEPLUGINS is not nice nor performant)
  • Establishing rendering order. At the end this mean "render plugins tags emmited by other plugins until there is none left"
  • Create patterns of use of plugins. This could be better acomplished using the PluginOOApi approach.

-- RafaelAlvarez - 16 Sep 2004

A centralized place to configure plugins doesn't necessarily mean storing the configurations in one place.

It may be that using direct save forms and redirection back to the configuration topic you could keep the storage on plugin topics but use a search to generate the configuration page. However, this would require functionality to enable replacement of topic content on direct save and redirection via url that we don't have at present.

-- SamHasler - 17 Sep 2004

What about making that functionality a plugin?

A plugin could pull the settings from the various topics to render a page with all the settings in a user-friendly manner. The page should post the new configuration to a cgi script that then push the info in the relevant topics.

Does this make sense?

-- RafaelAlvarez - 17 Sep 2004

Probably not a good idea to have plugin configuration dependant on a plugin.

The point I was trying to make was that we may in future be able to do this with just core functionality. If we could implement UserSpecifiedRedirect and UsingFormsForSettings and switch plugins to use forms instead of settings we could do the rest with searches and directsave. Although you might need AllowMultipleForms / MultipleFormsPerTopic as plugins already have a form.

It's possable that central plugin management may fall out of some other feature enhancement like EmbeddingFormsIntoTopics or ImplementSubPageEdit with some enhancement to allow edit of sections included from other topics.

-- SamHasler - 17 Sep 2004

Seems like I didn't explain myself. I'm proposing and additional way to configure the other plugins, the old mechanism is left in place so you can either use the plugin topic or the unified configuration page.

-- RafaelAlvarez - 17 Sep 2004

That's what I'm describing. I just think you can keep the configuration stored on the plugin topics, but edited from a single page. That way there would be no confusing duplication of configurations.

-- SamHasler - 17 Sep 2004

Central plugin management makes me a bit nervous, simply because of the performance hit implied by plugin work on every view. As long as you can minimise (or even reduce) the work done for each view for each plugin, then I'm still interested....

-- CrawfordCurrie - 18 Sep 2004

I'm not sure why you think this would slow the plugins down. It's probably my own fault due to my vague explanations above.

-- SamHasler - 18 Sep 2004

Just paranoia, probably. The plugins mechanism already in place is a dog, and I'm nervous of anything that slows it down further.

Plugins don;t just affect performance through the discovery mechanism. All the hooks in the core code work by iterating over the installed plugin handlers, and this slows down the code. While it makes plugins management easy to discover at runtime, it is inherently slow.

I'd rather we thought about a mechanism that lets us install plugins statically. For example, a Perl module that is written by the PluginsInstaller that contains the perl code for the plugin hooks calls. You lose the flexibility of being able to switch plugins in and out at runtime, but you could still "manage" them i.e. disable/enable etc. easily enough. I'm attracted by the idea of moving the load from the runtime to the compile, because then accelerators like SpeedyCGI and ModPerl can help improve their performance.

-- CrawfordCurrie - 19 Sep 2004

This is what I envisioned! http://textpattern.com/screenshots/?s=pluginlist

-- RafaelAlvarez - 03 Nov 2004

yes please - talk to WillNorris - he's working on TWiki installation code at the momement, and said on irc that he may have some thing suitable for this already

-- SvenDowideit - 03 Nov 2004

Plugins are now discovered during configuration (Dakar release)

-- CrawfordCurrie - 11 Jan 2006

Edit | Attach | Watch | Print version | History: r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r4 - 2006-01-11 - CrawfordCurrie
 
  • 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-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.