Core features - what stays in

[bolverk]

I think literally one of the first things you need to do is define what existing features in the 3.x branch can be defined as a core bulletin board feature and should remain a feature in 4. This could arguably be one of the most difficult tasks and I'm sure will be a very contentious discussion. I'm not talking implementation or functionality here either, strictly high level feature inclusion. So how exactly do you determine what is a core feature and what is not? Well in my company we do this by creating and agreeing on a definition of *core feature* then assess each feature request independently to see if it meets that definition. I also want to point out that just because a particular feature may not meet the core definition and should be treated/developed as an extension does not mean that it cannot be authored by and packaged with phpBB as an optional install, just that it should not be installed by default.

Anybody else have different ideas on how to categorize features into core v. extensions?

[naderman]

I'd much prefer it if we came up with a system where it doesn't matter whether a feature is "core" or not.

[bolverk]

Every application must have a baseline feature set, or core. Without defining that how would you determine what features must be available in an 'out of the box' install?

There is also the problem that if a feature is not classified into core (phpBB owned) or extension (phpBB/3rd party owned), there is no development accountability (in terms of usability) for it's implementation.

[code reader]

i think we are a bit of disadvantage because we use unclear terminology.

let me say how i see it:
of course there is a "core". the core provide infrastructure services such as DB interface, session management, template processing, loads and call the plug-ins etc.

in addition, there is another distinction: "in-the-box" (aka "builtin") vs. "add-ons".

the important point is that not everything "in-the-box" is necessarily "core".
the idea is that a lot of the "in the box" capabilities are implemented as plug-ins and use the plug-in interface.

so the "in the box" consists of a lean-and-mean core, and a bunch of plugins. the user can enable and disable each plugin as she sees fit.
she can also add plugins not originally in the package. there is little distinction between "in the box" plugins and "addon" plugins. they behave exactly the same.

as much as possible of the "in the box" functionality can (and should, IMO) be a plug-in.
this has several advantages:
-- by minimizing the core it becomes more stable. only changes to the core require "upgrade". everything else is handled through "install a new plug-in version" which is significantly simpler than an upgrade
-- every feature which is implemented as a "plug-in", automatically gets enable/disable switch which operated exactly the same
-- we can much more easily fix bugs in specific plugins, and publish those fixes, or, worst come to worst, publish a warning: "version X of plugin Y is severly broken. until a new version is available, please disable plugin Y".
-- it is very natural to select a well-written, well-documented, well-supported popular external plugin and promote it to "in the box" status: in essence, it becomes a packaging question.


so, the way i see it, it is extremely important not to conflate "core" and "part of the basic package". probably some new terms should be used.
maybe we should retire "core" and use "kernel" and "basic package".

peace.

[Dog Cow]

the core provide infrastructure services such as DB interface, session management, template processing

But then again, maybe I want to provide my own session management, DB interface, and custom template engine. Shouldn't those be plug ins as well?

[naderman]

so, the way i see it, it is extremely important not to conflate "core" and "part of the basic package". probably some new terms should be used.
maybe we should retire "core" and use "kernel" and "basic package".

Again I agree with everything you wrote. I like that terminology a lot. I think we should stick to it.

[Dog Cow]

I think that the kernel's job should be no more than:
1.) Having a set of required plug ins which must exist.
2.) Loading those required plug ins, or exiting with an error
3.) Loading all other optional plug-ins
4.) Managing interactions between plugs ins.

To expand upon points 1 and 2, I envision the kernel's loading process going like this:

1.) At startup, the environment is tested for PHP version, compatilibilty, etc.
2.) A .conf file is loaded which has the names of the required plug ins for sessions, DB, template, etc.
3.) The kernel then examines the directory structure to try and load those required plug ins.

Directory structure could look like this:

root_dir/plugins/kernel/datastore/
root_dir/plugins/kernel/sessions/
root_dir/plugins/kernel/template/

Within these directories could reside one or more files which provide the necessary plug ins. For example, in datastore, we could have two plugins: a DBAL, and a NoSQL plug in. If the plug in mentioned in the .conf file exists, then the kernel will load it and proceed as usual.

Point number four could be implemented with a Singleton container such that the plug ins can send messages and data to each other.

[naderman]

Please keep in mind that the directory structure should follow http://groups.google.com/group/php-stan ... l-proposal as per http://wiki.phpbb.com/PhpBB4/Programming#Standards . I also explained on the wiki that I consider those "libraries" - like session, dbal, etc. - to be components that provide services. These would be configurable through the dependency injection container. I'd really like to use the symfony component for that, it can compile the configuration to PHP which makes it really fast. Plugins on the other hand change or extend board functionality. The kernel contains a set of default components and some basic functionality on top of that to handle plugins. Plugins should also be able to depend on components that are not a part of the kernel. Those components would then be installed as a dependency. The advantage is that their generic functionality would also be available to other plugins.

[bolverk]

so, the way i see it, it is extremely important not to conflate "core" and "part of the basic package". probably some new terms should be used.
maybe we should retire "core" and use "kernel" and "basic package".

Here we are starting to diverge I think, because what you are getting hung up on is nothing more than semantics, in fact *core* is the most frequent word used to define kernel, which typical end users do not understand. Don't get hung up overcomplicating something as basic as a standard feature set. 'Out of the box' in the context I used was meant as nothing more than what features are included in a vanilla install which IMO should not be anything other than the basic core feature set.

[naderman]

The differentiation is important here because we want even those basic package plugins/features to be removable if someone would want to do that.