create new tag
, view all tags
In reviewing the implementations of the plugins, it appears that there is a fair amount of very similar code in several of the plugins. It would be good to leverage this shared code for all our benefits.

In the past, it has been difficult to get changes needed by plugins into the core. This is due mainly to the overload experienced by core team members. It would be good to find a way of reducing this load.

To address these two issues, I propose that we create a shared code directory in the Plugins CVS. The directory will hold code used by multiple plugins but not available from the core, and will also contain a buffer zone, driven by the plugins authors, that will extend the interface provided by the TWiki::Func module. The directory will be maintain by the plugin authors, not by the core team, on an open-access basis.

While the risks of allowing checking access for plugins authors should be relatively small - after all, you can already check into the plugins repository where you want - we do need a few protections. To that end, I propose we establish some operating standards for code that goes in the shared area:

  1. Releases will only be made from CVS.
  2. All code modules in the shared directory will have accompanying tests that can be run by any developer or installer (c.f. CPAN "make test").
  3. All modules checked in must subscribe to a consistent build/install philospophy i.e. there will be a script that builds the module into a target installation. Any code checked into the shared area must be built & tested by this makefile.
  4. Anyone can check a module in to the shared code area, but, following the wiki principle, anyone else can chuck it back out again if they don't like it (e.g. broken, tests not good enough, documentation not good enough).
  5. Again following the wiki principle, any code in the shared area is open to refactoring by another developer.

I appreciate that there are a lot of details to be worked out - for example, how to manage dependencies - but I think the best way of getting them worked out is to create the directory and see what happens. To this end, I've created a list of some of the "tasks to be done" at the end of this topic, with a prioritisation for each. Rather than entering a lengthy discussion, I would ask all who subscribe to this proposal to add and prioritise the tasks they think need doing - and then pick the next most important task off the list and do it! (priorities are on a scale from 0 to 1000, where priority 0 is most important). If you disagree with the proposal, then please feel free to comment constructively!

-- CrawfordCurrie - 20 Mar 2004

Great initiative Crawford.

Core Team: As Crawford is the most engaged in this process, is competent and aligned with all of our needs, how about acknowledging his efforts and broadening his powers by granting him Core Team rights and giving him formal charge over this initiative?

Additionally, I invite one of the skin authors consider taking up ConsolidateFunctionalityFromSkins - I think there is not too much overlap from Crawford's role and this also desparately needed to reduce dissipation of efforts and to reduce overall complexity.

-- MartinCleaver - 20 Mar 2004

I hope these things can be accomplished without requiring CoreTeam permissions

-- WillNorris - 21 Mar 2004

this sounds like a very promising initiative. don't forget to leave space for those who aren't coders, but still have CVS access. I'd like to help but don't see anything (yet) in your outline that I'm qualified for; perhaps running some the tests you mention (?).

PS: it might help to encourage cvs use if the "yes" following DeveloperVersionInCVS was a hyper link to that cvs entry.

-- MattWilkie - 21 Mar 2004

I also hope this can be accomplished without bothering the core team. Core team membership is not required to do this, though it would help to be able to rename/delete topics in the Plugins web. Matt, good idea about the hyperlink; I have no idea how to do it, though! Non-coders are of course welcome; one of the things that needs doing is to help out busy core team members and check in the latest versions of their plugins in CVS, for example. I really don't believe we should be releasing code that is not source-controlled in the TWiki distribution. Also, I'm not a "skin person", I don't know what shareable elements skins may bring to the party and how they should be handled.

-- CrawfordCurrie - 21 Mar 2004

I think it is a very good idea, having a way to consolidate things in a decentralized fashion, and to test interoperability of proposals. I feel we shall get going on this, and see how it develops, no need to over-design it from the start

-- ColasNahaboo - 24 Mar 2004

I'm very glad to see this - If you need anything from the core team, we're here to help smile I expect to be busy working on core issues for a while yet though ...

-- SvenDowideit - 24 Mar 2004

A spec for shared code for Plugins is certainly something useful. It can be done without the core team / we will assist you where needed.

From the user perspective, KISS is key. In my view shared code can be viewed simply as yet another Plugin that provides functionality for other Plugins. That is, if you want to install FooPlugin you need to install also BarPlugin; the BarPlugin topic contains to API doc; the FooPlugin would instantiate TWiki::Plugins::BarPlugin:SomeUsefulClass.

The primary location for stable Plugins is the ZIP file attached to the Plugin topic in this Plugins web.

We should offer both options, a manual and an assisted installation of Plugins. The manual one is the same as now, download ZIP and unzip (with the need to download and unzip also dependent Plugins). An install script could check for dependencies and report if a dependent Plugin is missing or outdated. Optionally it could grab the ZIP from the Plugins page.

Again, KISS is key, e.g. better not to depend on a CVS configuration to get a stable package. The CVS repository is good for development and Alpha versions. Stable packages should be attached to the Plugin home.

Some shared code that is needed by many Plugins should go into the TWiki core. For example, time manipulation functions are needed in several places. We could provide a TWiki::Func::Time module for that. The SpreadSheetPlugin, CalendarPlugin, etc could make use of it.

-- PeterThoeny - 02 Apr 2004

I'd like to be able to offload the configuration problem on the client, but as evidenced by the feedback we see on TWiki usability, installation and configuration problems rank very high in the reasons most frequently given for not adopting or trying TWiki. One of the things about the plugins web is that unlike the core, there is no single stream of releases. Plugins are constantly being updated and re-released, and dependencies shift and change over time. Relying on the user to understand and manage these dependencies is unreasonable.

I think perhaps you are misunderstanding the role of CVS in the process. CVS is our configuration management system; development should always be done in the context of a CM system. When code is ready for release, then an automatic process run over that repository should be all that's required to build the release. This is only possible if release packages ("the zips" in plugins standard terminology) are always be built out of the CVS repository. Effectively the generation of a zip constitutes a "baseline" of the repository. This is basic release practice (see any standard text on managing software projects). Of course it only applies to plugins in CVS; any plugin submitted that is not in the repository will of necessity be excluded from the dependency and build mechanisms.

Unfortunately relying on shared code getting into the core is not an option for plugins authors, as we have experienced over the last few years. The cycle time is simply too long. I would far rather see the performance of the plugins discovery mechanism improve than have more functionality drawn into the core anyway.

-- CrawfordCurrie - 02 Apr 2004

I'd like to see a common all-plugins cvs module as well. It could be called CVSROOT/twikiplugins DivinaCommedia or CVSROOT/twikiplugins Inferno


(when I first wrote that I thought I was speaking with tongue in cheek... I think I've changed my mind)

What can I do to help make that happen?

-- MattWilkie - 03 Apr 2004

Also see RestructurePluginsDevelopment

frown not started cool! in progress big grin completed

Task Priority Being done by Complete
Create a directory in CVS, twikiplugins/shared/lib/TWiki/Plugins, to be the SharedCodeArea 100 CrawfordCurrie big grin
Contact plugins authors who have checked into CVS but subsequently released new versions without updating CVS, and help them BringCVSUpToDate (see PluginsConformanceReport) 200 MattWilkie cool!
Examine ConsolidateFunctionalityFromSkins & list tasks here 250 MartinCleaver frown
Define TestenvInterface to permit CPAN & internal dependencies to be checked by installers (requires CoreTeam cooperation) 300 WillNorris frown
Define UnitTestStrategy 400 CrawfordCurrie cool!
Define MakeStrategy 500 WillNorris cool!
Test out idea of spoofing recent changes to plugins API in shared code 550 CrawfordCurrie frown
Convert existing plugins to MakeStrategy 600   frown
Define interfaces to unpublished TWiki components already in use by plugins 600   frown
EliminateUnpublishedSymbols; convert references to unpublished TWiki:: symbols out of accessible plugins to use shared code 700   frown
Create AutomaticPluginInstaller 750   frown
Convert existing unit tests to UnitTestStrategy 760   frown
Extract common code exemplar; attributes module from ActionTrackerPlugin, FormQueryPlugin, TWikiDrawPlugin and CommentPlugin 800   frown
Define a PluginBaseClass to simplify plugin authoring 900   frown

This text here to prevent Edit Table bug.

Edit | Attach | Watch | Print version | History: r16 < r15 < r14 < r13 < r12 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r16 - 2004-04-13 - MattWilkie
  • 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.