More in detail, these are some features already present here and there that I would like to see in CommonWiki :

• a StorageModule devoted to the interaction with either:
  • a database (DB, postgres, mySql ...)
  • a repository (RCS, VCS, ...)
• a VisualizationModule for the production of pages with
  • templates
  • different languages
  • Page features (counters, categories, register interest on a single page ...)
• a ParserModule to define:
  • different text formalisms (for automatic generation of html/xml)
  • different ways to define a WikiName
  • different ways to produce links (also between Wikis)
• an InputModule to generate topics by means of:
  • web forms (like in the WikiRegistration)
  • email (MIME also)
  • the current Edit form
  • to produce append-only pages
• a ManagementModule for the wikimaster operations
  • creation/renaming/moving of a complete WikiWeb
  • user registration/authorization handling
  • creation/renaming/moving a topic (between wikiwebs also)
  • management of templates
  • management of WorkFlow
• an AuthorizationModule for the cases where different parts of the same site must be managed by different people ... (I'm in a University .. .I'm thinking to Staff, Professors, Students and so on ...)
  • some way to define the authors allowed to modify a set of pages
  • management tools to add/move/expire authors
• PluggableSearch:
  • PurePerlBackendForSearch
  • SearchEnginePluceneAddOn
  • IndexServerSearchForMsIisAddOn

-- AndreaSterbini - 09 Oct 1999

Is this how it should be done? Should we do OOTWiki?

-- 02 May 2000

I'm absolutely certain the time has come to modularize and OOTWiki, but I'm thinking of the Perl-ish Tie::Whatever kind of OO. I vote against inheritance as the Way, I'd rather Use-a than Be-a. I propose that we design an interface spec, that it be the simplest possible spec, that we decide very firmly on core features and leave the hoo-hah to plugins. We vote, Peter decides, we volunteer. I think the first step is the interface spec, followed by a Wiki/Base.pm that provides a "traffic cop" (API glue) and very basic functionality... kind of the core language for writing a TWiki.

--Main.KevinKinnell - 02 May 2000

All this sounds like the next logical step, but it also means almost a complete rewrite of TWiki, e.g. a lot of work. One advantage of modularizing is that we have more scripts, e.g. less chance of edit conflicts among developers. I propose to keep adding incremental features until we have a clearly defined design of the new modular TWiki. Feel free to start braintorming on design issues.

-- PeterThoeny - 03 May 2000

Some work needs to be started on something along these lines. Once we've got a good breakdown of the various areas in the application when can then work on improving some specific feature set discussed elsewhere.

We have to decide how we want to create the modularization. Probably the best way is a perl package hierarcy. ie. from above:

• TWiki::Store
• TWiki::Parse
• TWiki::Visualize
• TWiki::Input
• TWiki::Manage
• TWiki::Access

I'm not sure if this is the best break down of the application structure, but that can be discussed further.

In order to start work on this, I'll get working the ::Store side of things. Further discussion on this will be in PackageTWikiStore.

-- NicholasLee - 12 Jun 2000

Sergio Fanchiotti has written APW (AnotherPerlWiki) deriving it from TWiki and wiki and is made of several classes. (and it's CPLed).

Please, master perl-ers, have a look at it, there is a chance that part of the modularization is ready.

-- AndreaSterbini - 21 Sep 2000

No unfortunately not, I've been too busy in RL. I'm working slowly on some basically modularization at the moment. The most useful thing people could do though, that I'm missing, it read PackageTWikiStore and comment on it.

APW looks interesting, I'll consider how we might be able to use it in TWiki.

-- NicholasLee - 21 Sep 2000

I started with the restructuring of TWiki. This is the first step of modularizing TWiki. The "itch" was to make it right for the new TWikiPluginAPI.

The first step is to create directories that represent future TWiki modules. Here is how the moved files look like (not renamed files not listed). All relative to twiki/bin.

Change has not yet been commited to TWikiAlphaRelease. Stay tuned.

-- PeterThoeny - 10 Feb 2001

Commited the changes to TWikiAlphaRelease in CVS. No functional changes have been made, but extensive structural changes related to introducing TWiki packages. With that we had to clean up the variable scope as well. Please note that I did only limited testing, thus it might not be as stable as the usual Alpha releases. We will do some more restructuring in the coming days.

-- PeterThoeny - 11 Feb 2001

Some things that Twiki desparately needs: (after having had to make a few installs & upgrades).

• An installer script. Many of the things TWikiInstallationGuide - discussion on TWikiUnixInstaller could very simply be automated.

• Upgrading a twiki installation often means a lot of faffing about with data & template directories. I'm currently using a "webs" directory & a bunch of symbolic links to make this task somewhat simpler. DataAndCodeSeparation

These are just a couple of practical concerns, but needs addressing IMO ASAP.(I'm working on both)

-- MichaelSparks - 03 Mar 2001

Once the TWikiBetaRelease is stabilised for feature freeze and well into release mode, I intend to create an experiment branch in the CVS. I dont want to do work other people have done already, so I'll probably speed up the patch-commit to branch cycle somehow. This should to speed up development in this area. Note: I expect because of this branch the will be broken 50% of the time.

My intention then in this branch, as I find time:

i) Rip out TWiki::Store's guts and create a slight refactoring that moves toward TWiki::Store::RCS with simple functional redirection from a TWiki::Store API. ii) Create a MakeMake Makefile.PL type install process.

With the API formed in i), with the next step would be: iii) Pure objectisation of TWiki::Store with some work say on TWiki::Store:CVS or ::DBI to explore problems in the API.

This with ii) should allow iv) upgradable data path via TWiki::Store.

ie. DataAndCodeSeparation

Its not that straight forward of course because of the dependancy problems between the bin/binaries and templates/, but its a step in that direction. I cant make this all happen overnight unfortunately, but this is the path.

The API will provide an minimum spec that a storage subsystem should provide in terms of information to the other parts of TWiki. I figure most of the important Storage related functions are actually in TWiki::Store at present. Its just a matter of making them generic and 'normalising' the result.

-- NicholasLee - 06 Mar 2001

At the start of the page a question is asked: Should we do *OOTWiki?* Modularisation is partly done/in progress... But to what extend is TWikiOO considered?

I've got no idea what it would cost in terms of performance to have an OO backend, but it's not to heavy, I would vote for TWikiOO.

Why use OO?

• Easy extendible backend, besides using the PlugIns
• Upgrading to new release should go easier without losing the local made extra's. These modifications are made in new objects, only the parent would package would change...

Why not use OO?

• Performance costs?? (could somebody put some numbers to this??)
• Requires PerlOO knowledge

Yes, going OO requires another rewrite of TWiki. However, it should be possible to do the change into OO gradually, reusing most of the available libraries. Currently I'm doing some coding using a TWikiOO lib besides the provided TWiki lib, and parts of my TWikiOO lib now directly call the original functions (thus now only providing a TWikiOO shell).
This approach could be used to develop and test a TWikiOO without making the base code unstable again.

When doing some minor stuff in TWikiOO, I noticed that a very good design is needed on the overall object structure (what is put where, how to call them, how to let them interact)...

KevinKinnell referred to using tie kind of OO. I'm not that into tie and OO that a bell's ringing. Some kind of pointers to examples would help... I've found some references, but that's only about hashes and arrays tied to make them also usable as objects.

-- HansDonner - 19 Sep 2001

Hans, is this moving forward on your end? Otherwise?

-- MikeMannix - 27 Dec 2001