Core features - what stays in

[bolverk]

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

That was pretty much my whole point in the first post of the topic. There has to be a defined set of features that are required for the application to function at all, just an empty framework with no standard features at all is well....useless.

[code reader]

at least the way i see it, by definition, anything in the kernel is *not* a plug in.

let me expand a little bit:
the kernel provides an API that the plugins use to execute their function.
you absolutely can use a plugin to modify *what exactly happens* when a certain API call is used, but even when no plugin exists, the API should still be there (so the first ever plugin has access to the full API)

the following section is an example just to illustrate what i mean, not anything worth arguing about the specific details.
let's imagine that part of this API is a function called
get_user()
this function can be overloaded: e.g., if you call it with a nick or with a user ID, it will return a user object for the user id or nick you passed (or null if no such user exists), and if you call it with no parameters it returns the user object of the currently logged in user.
in order for this to work, some level of session management should always be available, even when no plugin is loaded, i.e., "in the kernel".

now, let's assume a clever plugin whats to affect the way session management is implemented.
this is where the "hook system" comes into play. what happens after
get_user()
was called can absolutely be modified by some clever plug-in, with the right use of the plugin/hook system, but a bare-bone session management system that provides a well defined (and well thought of, i might add) API should be part of the kernel.

i hope i made myself a little bit clearer (to myself if to nobody else)

peace.

[Dog Cow]

at least the way i see it, by definition, anything in the kernel is *not* a plug in.

So I used the wrong term. Who here hasn't?

[code reader]

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.

i thought that this discussion is more geared towards architecture, not feature set.
feature set is extremely important issue, but, at least the way i see it, secondary to architecture.
you are probably right in that end-users are much more interested in feature-set, and much less care about architecture, but this forum (at least IMO) is not geared towards end-users, and rather meant more to discuss development and architecture.
an end-user might say: "i could not care less whether feature X is implemented in the "kernel" or as a "plugin". what i care about is whether feature X exists out of the box or not".
absolutely legitimate point of view, but from the *architecture* point of view, whether feature X is in the kernel or as a plug-in is *the only thing that matters*, while the question of "in the box" vs. "add-on" is completely uninteresting.

peace.

[Dog Cow]

but a bare-bone session management system that provides a well defined (and well thought of, i might add) API should be part of the kernel.

I think that the API should be well-defined as part of the kernel's programming docs, but the plug in/code/whatever that implements the API doesn't have to be integral to the kernel. It can just be another piece of code that the kernel is loading, albeit a required one in order for any user-level tasks to run.

[bolverk]

i thought that this discussion is more geared towards architecture, not feature set.

No, I named the topic "Core features - what stays in" for a reason. Defining the feature list is usually step #2 in feature driven design (agile model) and the overall system architecture is the first step, but in reality that has already been defined. -> An open extensible framework that implements core/standard features via the same mechanism as third party extensions. The functional discussions (the detailed implementation of specific features) should only happen after the architecture and feature set have been defined at the highest levels. While it is a huge step forward most of these topics are getting way ahead of the process by diverging into functional implementation discussions rather than sticking to identifying the high level components first. I would caution people to step back and stop looking at the how's when the what's have yet to be documented.

For example Lurttinen's feature request that morphed into "Package Management" is a high level feature that would have to be considered core, would it not? What would be the benefit of developing such a feature and then not include it by default?

[code reader]

but in reality that has already been defined. -> An open extensible framework that implements core/standard features via the same mechanism as third party extensions.

i guess we do not mean the same thing when we say "architecture".
what you quoted, in my book is not "architecture".
it is a nice (and important) criterion that the architecture should meet, and can be used to judge whether any specific architecture is successful in satisfying, but this is not architecture (at least not where i came from).

if i hire an architect and he tells me "you should have a tall building with wide doors and windows, within which different spaces will serve as living and utility rooms" i doubt he'll be able to collect his fee.

so, IMO, we still have a significant way to go before we can say "ok, we have our architecture nailed down".
at this point, you'll realize that the interesting question is not "which features in-the-box", but rather "which features in-the-kernel".
out-of-kernel stuff can be added to the box much much later in the process.
at least that the way i see it.


peace.

[bolverk]

i guess we do not mean the same thing when we say "architecture".

That would be correct. Every SAS I've written in the last 10 years was a one page UML diagram. I guess you can rename this topic whatever you want or abandon it because it went off the rails quite some time ago. Good luck.

[GameCharmer]

Basically, you want a system like Joomla, but forum based and MUCH easier to use, right?

Joomla runs off of extensions. It uses plugins, modules, and components, and probably something else, to generate pages.

In a nut shell...
Plugins - Change global stuff everywhere, but can be defined. Plugins are split into Front End/ Admin End style plugins.
Modules - More or less "blocks" that resemble Portal blocks of data. They can typically be placed anywhere on any page displayed to the user.
Components - A combination of plugin and module. Big components (such as photo galleries) are complete systems that install and integrate directly into the site and have tons of options for processing and display.

Of course, you still have modular templates.


Sorry for reviving a dead post, but I just wanted to more or less clarify what you are looking for. With Joomla, you get a core and a bunch of plugins, modules, and components, each of which can be altered, enabled, disabled, or even deleted so long as they don't destroy the core. You add new extensions by simply uploading a zip file with the proper files and installer inside and away you go!

[naderman]

I think the very fact, that you need different kinds of plugins already shows that your system is not flexible enough. phpBB MODs can change anything, we should aim to find a suitable replacement so people will not go back to making code changes in phpBB4.