Feature Proposal: Time to plan the new Foswiki core design.

Motivation

This proposal is a development of ImproveOOModel topic but with more specific focus on new core design.

Description and Documentation

As the original proposal was more about the general idea and about choosing the implementation framework I want this proposal to be more about structural changes to the code which would let us clean it up and, in particular, prepare for PSGI transition.

Design objectives

• Convert Foswiki to use an object oriented framework. CPAN:Moo was chosen as the new framework.
• Rationalize and refactor functions to be local to their related objects.
• Prepare Foswiki to operate under the control of CPAN:PSGI for better cross-platform compatibility.
• Establish framework to move away from deprecated Perl modules, for example CPAN:CGI.
• Compatibility with the Foswiki and TWiki APIs is not an objective. Limited compatibility may be investigated later through an adaptation layer like the old TWikiCompatibilityPlugin.

Where to start.

• ImproveOOModel unless you're already familiar with the issue.
• Foswiki3CodeChanges provides examples of the code changes required during this redesign
• Branch task for the current development. This is where I record raw ideas, make notes on issues I don't understand yet or have plans to get back to them later, etc.
• A release meeting agenda which could be considered as a draft for this proposal. There is IRC useful discussion log too.

List of areas to be considered

With this list I would like to define general areas of interest to be considered.

• Compatibility with PSGI architecture.
• Divide Foswiki.pm into independent modules. One to be a container for static low-level API functions like isValidWikiWord() and the rest of is*() functions. Another module to become a replacement of current session which is actually not the session as people usually understand it.
• Topic object. Few related and interesting proposals are already floating around and might be reconsidered again.
• New plugins model. Should a plugin be capable to influence or even replace some core processes? For example, current store model could be replaced by new plugins. Same plugins may register additional macros for the frontend for purposes like providing some statistics or control functions to the admins. I leave the issue of compatibility with the old plugins aside but it it has to remain in place and it's only a matter of which way it has to be implemented.
• Clean and structured exceptions tree. This item would highly depend on all the previous ones.

Related proposals.

Discussing everything design solution in this very topic would make this place a mess. So, I propose to have a separate topic on each subject. In this section every related topic is to be listed. Additionally I propose to have them named starting with Moo prefix to unify and keep them close to each other in searches.

MooFoswikiPm	The core of it all: Foswiki.pm and session object. Split and transform.	edit
Handling of $Foswiki::cfg{Store}{ImplementationClasses}	It needs to be rethought.	edit
QuoVadisPsgiFoswiki	Discussion of benefits and implementation of PSGI	edit
ImproveOOModel	General discussion of OO improvements in Foswiki	edit

Impact

This will break compatibility with existing plugins. Plugins closely using the API will need minimal changes. Plugins that have any dependency on internals will need significant changes.

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: VadimBelman - 26 Feb 2016

Discussion

Commenting is disabled while not logged in