stale_content1Add my vote for this tag create new tag
, view all tags
Someone recently pointed me at the Plugins page and told me to read it as an explanation of why they don't "trust" plugins. There are two things there that might give a poor impression:

  1. The quote from Dante. While I appreciate the humour, this gives the impression to the uninitiated that they are entering the seventh circle of hell; which is an unfair reflection on most, if not all, of our plugins.
  2. The second thing is the comment "perhaps sometimes with a lesser focus on quality than the core code". Perhaps this is true for some of the plugins, but many of the contributions are very high quality indeed, and this reflects badly on them.

I think the plugins deserve better recognition than that, but it's really hard when some plugins are very high quality and regularly maintained, but others are perhaps not.

We have one way today of giving a plugin the "seal of approval", and that's to install it on twiki.org. That implies that it is trusted by the core team. But obviously we shouldn't just install plugins just to let people know they work. There has to be a better way.

Some ideas:

  1. A plugin rating system; gold, silver, bronze awarded by the core team.
  2. A user feedback section for each plugin, where customers can record their reviews.
  3. A rewrite of plugins Plugins, suggesting caveat emptor rather than duck!.
  4. All of the above.

-- CrawfordCurrie - 13 Dec 2003

I agree (although I do find it frustrating that requests such as those in PleaseInstallPluginsAtTWikiDotOrg went unheeded.)

I think that having a user-contributed ratings system would help, preferably something very low effort with which people could click what they thought rather than requring people to have to a write a sentence. In many senses, this is a second need for a SurveyPlugin . I'm imagining a survey form collecting responses into topics named such as XxPluginReview from which a SEARCH can provide aggregate opinions.

One of my aims for the TWiki Deployment spider was to gather the list of plugins each public site was using. Once I've finished my last essay this term I'll have some time to develop it some more.

-- MartinCleaver - 13 Dec 2003

Crawford, you bring some good points. I removed the "lesser focus on quality" note but left the Dante quote.

So far we have only three Plugins preinstalled in the TWiki distribution package, with 6 more scheduled to be included. Over time we will add more Plugins. Included Plugins are a sign of an official stamp of approval. See PreinstalledTWikiPlugins.

As Martin notes, a user voting mechanism that is easy to use would help. Follow-up in CoolFactorRatingOfPlugins.

-- PeterThoeny - 14 Dec 2003

Additionally I would like to DocumentPluginPerformance.

-- PeterThoeny - 23 Dec 2003

I think that bad performance is inherent to the current Plugin mecanism. In my opinion, this should be changed first. I am not a perl programmer, but points which strikes me as inefficient are:

  • Nothing should be done at runtime to registrer a new plugin. Some script should be called to install/deinstall a plugin, modifying perl code. Now each time a page is viewed, the list of all possible plugins are scanned, initialized, etc..
  • Now the text body is scanned wholly N times, for each possible %-var. An obvious optimization would be to just scan the body ONCE for an %-vars, such as: %[A-Z0-9_]+({.*?})?%, and for each match, call the plugin-provided function/method registred for each var, stocked in an hashtable, that could be statically defined in a perl module, so that even its instanciation could be done at server start when using perl_mod, not on each request. This plugin install script would thus just add/remove lines in this .pm file...

-- ColasNahaboo - 30 Dec 2003

copied Colas' observation to ImprovePluginStartingTimes

-- MattWilkie - 03 Jan 2004

Interesting sugestion , i have wanted Plugin installation to be done from a TWikiTopic, with a script that puts all the files in the right place etc. so the UI is similar to Upload. Registration (generation of the installedPlugins.pm file) could be taken care of then too. However, the optimisation seems to me to be stacked in favour of a rendering hash (maybe we don't even need to use a hash) - and the other hooks might be less trivial)

so installedPlugins would contain one function per pluginHook, that the install process would add each of the plugin's methods to (wonder how we define order), and from that point on, they get called via that? OR do we expand the plugin's method in place in installedPlugins.pm?

should we make this a major freature of Dakar?? (assuming others like it)

-- SvenDowideit - 03 Jan 2004

Small notes:

  • debian install scripts does already this for apache's httpd.conf file: it adds/remove (comments out, actually) the module loading lines, which can be seen as plugins
  • order: one could have optional dependency infos added to the plugins, such as: (this could be optional, not needed for a first implementation)
    • must be called before/after plugin Y. A simple mecanism would be to use the unix /etc/rc.d convention: name the plugins NNfoo, and order the plugins calls by their numbers NN
    • depends on plugin/feature Z

-- ColasNahaboo - 05 Jan 2004

Now that plugins built with BuildContrib ship with an auto-generated installer script, this idea becomes more credible. In fact, it would be downright straightforward BUT it would mean that you can't install a plugin just by unzipping, which has always been one of Peter's hot-buttons.

-- CrawfordCurrie - 09 Sep 2004

Is the installer script capable of handling plugin upgrades intelligently? E.g. uprades the plugin but doesn't clobber personalisation/localisation/security settings.

If yes, then it's better than unzip'n'go, which can't do that, ever.

-- MattWilkie - 10 Sep 2004

No, it's a post-install script, so must be preceded by an unzip - which is the most likely thing to clobber you. There may be scope for a real install script, that you download instead of the zip. Or the post-install could be made to work like UpgradeTWiki, and patch from a neutral directory into the target installation.

Any offers of assistance to improve the script would be most welcome.

-- CrawfordCurrie - 10 Sep 2004

  1. How about we make an install of TWiki at twikiplugins.sf.net with everything installed? Slow it would be but it would allow us to test for coexistability, functionality, and interoperability.
    • Eventually we'd aim at a nightly rebuild and install
  2. Let's find a more responsible-encouraging quote. "Abandon all hope" is just not inspiring
  3. I don't believe in this "just unzip TWikiExtension .zip" - it relies on the plugin author having followed all the rules.
    • What if a plugin author accidently packages a lib/TWiki.pm file? It would obliterate any changes that user might be considering to feedback to TWiki.
    • Consider the excellent KupuEditorAddOn - its zip file is non standard.
    • Consider that plugin authors sometimes accidently package a XPlugin.txt,v file - installing that would obliterate the user's history of customisations for the plugin.

I believe we should have a twiki-provided script for installing plugins. This would download, unzip appropriate files (and warn about non-comforming ones in the zipfile), check for dependencies and handle upgrade of plugin topics. We are almost there. I think that the work I have been doing in BuildContrib to create a TWikiShell (currently called twikicli) combined with Crawford's functionality for installation should do it.

  • I reckon we'll have this done, as an output of our trip to Fontainebleu.

-- MartinCleaver - 10 Sep 2004

Let's try to get the idea behind the "just unzip" install. From my point of view, "Just unzip" install means "easy install" or "one click install".

The problem with an installer script is that is must work in every enviroment (hey, I have Twiki on linux, windows + cygwin and windows with unixutil), and must not rely on some program to be on the path (on my windows box, Perl is not in the execution path). This can rule out shellscripts and batch files.

A Perl installer seems to be the right solution, after all "unzip PluginPackage.zip" is no harder than "perl tools/install.pl PluginPackage" and anyone with minimun admin skills (see AdminSkillsAssumptions) can make the scripts or files to ease the process. Or we can provide them for [li|u]nux and windows.

See PluginsInstaller for a proposal

-- RafaelAlvarez - 10 Sep 2004

Edit | Attach | Watch | Print version | History: r17 < r16 < r15 < r14 < r13 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r17 - 2004-11-10 - SamHasler
  • 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.