So, this is a question and a comment, though the comment may be irrelevant, depending on the answer to the question...
The question is not purely technical, though it has technical implications, and is indicated in the title:
My question is: how does the team see future development, WRT "will it be in core or will it be an extension".
based on some glimpses and discussions i read here and on phpbb.com, it seems that the general view is, all (or most of) the development done by the core team should reside in the core product, and all the development done externally (i.e., by out-of-team developers) should be in extensions.
I might be wrong in this impression, but the recent announcement that "mod team" will become "extension team" seem to indicate that generally speaking, this is the direction, and the view is that "core vs. extensions" will follow the same pattern that "core vs. mods" has on 3.0 and 2.0 .
So, first thing a question: is it really so?
if not, can someone describe what is the direction regarding the question in the title?
If the answer is "Yes", I'd like to advocate a different approach, together with some consequences to be considered if the alternative approach is used (the rest of this post is this "advocate", and it's the "comment" i mentioned above).
IMO, ideally, the core should contain as little as possible, and a lot of functionality, that currently resides in "core" should really exist in extensions. As a corollary, in the future, most of the development done by core team, should be in extensions and not in "Core".
Now, for stuff that's already exists in core code it may or may not make sense to migrate to extension, so in my example i'll pretend the system is engineered today, just to illustrate how i see the "correct" division.
some examples of functionality currently in core, that could and should be in extensions:
-- bbcodes
-- private messages
-- polls
-- backup/restore system
-- avatars system
-- file management (aka "attachments")
-- the stuff that was previously distributed as "plugin": search, authentication, captcha, etc.
-- prolly more stuff, but i'll stop here...
in order to facilitate this, some technical things need to be done (i'll admit, i somewhat lost touch, so some of these things may already exist in the code, though i do not think so):
-- Strong extension-dependency system: I should be able to declare that my extension depends on some other extension, including "minimum version", and if the other extension is not installed/present, my extension will not be loaded even if it's installed.
-- (to support dependency): some formal extension namespace definition, to prevent or at least minimize the probability of two different extensions having the same name. e.g., all extensions developed by core team can be called "Phpbb.XXXX", and extensions developed by some 3rd party developer named Alonzo will be called "Alonzo.XXXX"
-- (also to support dependency) strong and formal extension-version definition
-- make it clear to developers that extension, just like core, must be backward compatible: for instance, if an extension defines a new hook, all future versions of this extension must continue to support this hook, etc.
Some non-technical attitude adjustments that need to happen if this direction is chosen:
-- distribution/deployment should contain a number of "default extensions" that are distributed with the core product, and enabled by default, but can still be disabled by the person installing the system
-- most of "core team" activity should switch over time to extension development
-- roles of different "teams" in phpbb should be re-considered. specifically, the "extension team" should have a different name and different role definition
again, i was somewhat removed from phpbb activity, and it is possible that what i wrote is really complete nonsense or irrelevant to phpbb project at this time.
Be it as it may, I'd like to hear how other people think about this "core vs. extension" division, in terms of code, team, and team/community relationships.
peace.
Core vs. Extensions
Re: Core vs. Extensions
This was brought up some time ago by Steve (Pony99CA). If he sees this topic, I'm sure he'll dig it up and link to it.code reader wrote:ideally, the core should contain as little as possible, and a lot of functionality, that currently resides in "core" should really exist in extensions
The only thing I would agree with splitting off would be polls, but even that is a stretch because a lot of boards use them.code reader wrote:some examples of functionality currently in core, that could and should be in extensions:
-- bbcodes
-- private messages
-- polls
-- backup/restore system
-- avatars system
-- file management (aka "attachments")
-- the stuff that was previously distributed as "plugin": search, authentication, captcha, etc.
-- prolly more stuff, but i'll stop here...
Dependency and namespaces are already implemented for extensions.code reader wrote:-- Strong extension-dependency system: I should be able to declare that my extension depends on some other extension, including "minimum version", and if the other extension is not installed/present, my extension will not be loaded even if it's installed.
-- (to support dependency): some formal extension namespace definition, to prevent or at least minimize the probability of two different extensions having the same name. e.g., all extensions developed by core team can be called "Phpbb.XXXX", and extensions developed by some 3rd party developer named Alonzo will be called "Alonzo.XXXX"
I'm not sure I follow here. Can you explain a bit better?code reader wrote:-- (also to support dependency) strong and formal extension-version definition
Most of the officially supported extensions are actually created by the Extensions Development Team, and you will notice a number of team members are on that team. With regards to your last point, the Extensions Team is what the MOD Team was to 3.0. They are responsible, primarily, for validating submitted extensions to the Customization Database. The Development Team has always been responsible for the development of the product, the Support Team supports the product, the Styles Team is responsible for styles, etc. I'm not sure how there is any confusion as to what team is responsible for what.code reader wrote:-- distribution/deployment should contain a number of "default extensions" that are distributed with the core product, and enabled by default, but can still be disabled by the person installing the system
-- most of "core team" activity should switch over time to extension development
-- roles of different "teams" in phpbb should be re-considered. specifically, the "extension team" should have a different name and different role definition
Re: Core vs. Extensions
The first things that I want to point is that phpBB is a forum software, it's not a framework but a software that can be extended by some extensions.
Otherwise the idea is to provide a software with the functionality required by the majority (or at least required by an important part of the community). We could split the core to extract some features into a bunch of extensions/components included and enabled by default but I'm not sure that it will be the best idea: it's phpBB and not a new Symfony kernel which use extensions instead of Bundles.
Anyway it can't be done before we get rid of all the legacy codebase (so not before the 4.0 and a "few" of years)
EDIT: For me, if a features directly related to a forum (like attachments) is requested by the majority of the community, it should be in the core.
EDIT2: The idea (in the future) is to use composer to manage the extensions and so handle the dependencies. (viewtopic.php?f=108&t=43427)
Otherwise the idea is to provide a software with the functionality required by the majority (or at least required by an important part of the community). We could split the core to extract some features into a bunch of extensions/components included and enabled by default but I'm not sure that it will be the best idea: it's phpBB and not a new Symfony kernel which use extensions instead of Bundles.
Anyway it can't be done before we get rid of all the legacy codebase (so not before the 4.0 and a "few" of years)
EDIT: For me, if a features directly related to a forum (like attachments) is requested by the majority of the community, it should be in the core.
EDIT2: The idea (in the future) is to use composer to manage the extensions and so handle the dependencies. (viewtopic.php?f=108&t=43427)
Member of the phpBB Development-Team
No Support via PM
No Support via PM
Re: Core vs. Extensions
Phpbb as a complete forum software package or core package is always developed by the team.
Extensions are for adding on to phpbb new features and abilities.
The op seems to have noticed the fact that many times people ask for new optional features to be added to the core and often times we say those would be better done as extensions.
This basic development model is the same as it has always been since phpbb 2.
Extensions are for adding on to phpbb new features and abilities.
The op seems to have noticed the fact that many times people ask for new optional features to be added to the core and often times we say those would be better done as extensions.
This basic development model is the same as it has always been since phpbb 2.
Has an irascible disposition.
-
- Registered User
- Posts: 653
- Joined: Wed Sep 21, 2005 3:01 pm
Re: Core vs. Extensions
IMO, this is false logic.tmbackoff wrote:The only thing I would agree with splitting off would be polls, but even that is a stretch because a lot of boards use them.
why the fact that many boards use something should be a factor for the question of whether it should be core or extension?
this attitude is what i sense is the current prevalent attitude of phpbb developers, and exactly what i'm trying to argue to be misguided attitude: IMO, the "core" should contain all the infrastructure, plus core forum functionality: hierarchical discussion forums, user management and permission system, and as little as possible of anything else. polling is not core forum functionality, regardless of how many boards use it. private messaging is not core forum functionality. signatures and avatars are not core forum functionality. i do not advocate exiling all of those to extensions, not because they belong in core, but because phpbb has too much legacy code for it to be practical.
however, IMO, if someone would be creating a modern, well designed forum package that needs to match phpbb functionality, those things should be in extensions.
(the question was about dependency and versioning):tmbackoff wrote:I'm not sure I follow here. Can you explain a bit better?
what i meant is that it's not enough for a package to say "i depend on package X" - it should be able to say "i depend on package X with version greater or equal to A.B.C"
the point i was trying to make is that if we think of "extension/core" as packaging issue, rather than as "who wrote it", then, according to your description above, i think "extension team" is poorly named.tmbackoff wrote:Most of the officially supported extensions are actually created by the Extensions Development Team, and you will notice a number of team members are on that team. With regards to your last point, the Extensions Team is what the MOD Team was to 3.0. They are responsible, primarily, for validating submitted extensions to the Customization Database. The Development Team has always been responsible for the development of the product, the Support Team supports the product, the Styles Team is responsible for styles, etc. I'm not sure how there is any confusion as to what team is responsible for what.
what this team really does is validates and filters community contribution, and it should be named accordingly. the fact that community contribution came in the form of MODs in 3.0.x, and will come in the form of extensions in 3.1.x is important, but it does not really change what the team does.
if we view "extensions" as a legit way for core developers to add functionality (as i advocate), we do not really expect the "extension team" to take responsibility for these core-development-team supplied extensions. so it would be better to find more appropriate name for the "extension team", that will highlight the fact that they deal with community-contributed code, rather than the uninteresting fact that this code is typically packaged as (mods/extensions/plugins/whatever).
you are mixing two unrelated criteria: "complete forum software" vs. "new features".VSE wrote:Phpbb as a complete forum software package or core package is always developed by the team.
Extensions are for adding on to phpbb new features and abilities.
the fact that something is new does not necessarily mean it does not belong in "complete forum software", and conversely, the fact that something is old does not necessarily mean it *does* belong in "complete forum software".
for instance, some will argue that the ability to rate posts ("like/hate") belongs in "complete forum software", yet it's not part of phpbb, and some others may argue that private messaging has nothing to do with "forum software" (and indeed, many forums ranging from NNTP to stack overflow do not support PM).
to summarize: my point is that i think we are conflating between "where does it belong" and "where did it come from", with the obvious (and, IMO, wrong) answer that "if it came from core team it belongs in core package, and if it came from community, it belongs in extension".
this is simply not true. i do not remember if VSE was around in the days of phpbb2, but let me ask this: what was the closest equivalent to community member sending a "pull request" in the 2.0 days?VSE wrote: This basic development model is the same as it has always been since phpbb 2.
nada.
not only was community contribution extremely limited in 2.0 days (basically limited to MODs), but i remember quite a lot of core team members maintaining elaborate development branches that significantly modified dozes of files in private repos, not visible/accessible to the community, for months on end, which were eventually either discarded, or dumped as one huge "patch bomb" on top of the code base.
the current development model is very very far from being similar to the 2.0 development model.
as far as i know, none of the current core developers was a community member in 2.0 days, but if one or some of them were, just ask them.
peace.
Re: Core vs. Extensions
Their is also an Extension Development Team which develop a bunch of official extensions (so supported by phpBB itself).code reader wrote:the point i was trying to make is that if we think of "extension/core" as packaging issue, rather than as "who wrote it", then, according to your description above, i think "extension team" is poorly named.tmbackoff wrote:Most of the officially supported extensions are actually created by the Extensions Development Team, and you will notice a number of team members are on that team. With regards to your last point, the Extensions Team is what the MOD Team was to 3.0. They are responsible, primarily, for validating submitted extensions to the Customization Database. The Development Team has always been responsible for the development of the product, the Support Team supports the product, the Styles Team is responsible for styles, etc. I'm not sure how there is any confusion as to what team is responsible for what.
what this team really does is validates and filters community contribution, and it should be named accordingly. the fact that community contribution came in the form of MODs in 3.0.x, and will come in the form of extensions in 3.1.x is important, but it does not really change what the team does.
if we view "extensions" as a legit way for core developers to add functionality (as i advocate), we do not really expect the "extension team" to take responsibility for these core-development-team supplied extensions. so it would be better to find more appropriate name for the "extension team", that will highlight the fact that they deal with community-contributed code, rather than the uninteresting fact that this code is typically packaged as (mods/extensions/plugins/whatever).
This is the purpose of the RFC process.code reader wrote:you are mixing two unrelated criteria: "complete forum software" vs. "new features".VSE wrote:Phpbb as a complete forum software package or core package is always developed by the team.
Extensions are for adding on to phpbb new features and abilities.
the fact that something is new does not necessarily mean it does not belong in "complete forum software", and conversely, the fact that something is old does not necessarily mean it *does* belong in "complete forum software".
for instance, some will argue that the ability to rate posts ("like/hate") belongs in "complete forum software", yet it's not part of phpbb, and some others may argue that private messaging has nothing to do with "forum software" (and indeed, many forums ranging from NNTP to stack overflow do not support PM).
Also, as I said before phpBB is an independent software, it's not a modified version of Symfony (or any other framework) with a basic forum bundle enabled by default.
But as it was said before, all the code written by the dev team is not part of the core. Their is a lot of MODs (and now extensions) which are written by some members of the dev team. And some important parts of the core was never written by a member of the dev team.code reader wrote: to summarize: my point is that i think we are conflating between "where does it belong" and "where did it come from", with the obvious (and, IMO, wrong) answer that "if it came from core team it belongs in core package, and if it came from community, it belongs in extension".
naderman is in the dev team since 2005code reader wrote:this is simply not true. i do not remember if VSE was around in the days of phpbb2, but let me ask this: what was the closest equivalent to community member sending a "pull request" in the 2.0 days?VSE wrote: This basic development model is the same as it has always been since phpbb 2.
nada.
not only was community contribution extremely limited in 2.0 days (basically limited to MODs), but i remember quite a lot of core team members maintaining elaborate development branches that significantly modified dozes of files in private repos, not visible/accessible to the community, for months on end, which were eventually either discarded, or dumped as one huge "patch bomb" on top of the code base.
the current development model is very very far from being similar to the 2.0 development model.
as far as i know, none of the current core developers was a community member in 2.0 days, but if one or some of them were, just ask them.
peace.
Member of the phpBB Development-Team
No Support via PM
No Support via PM
Re: Core vs. Extensions
I like the idea. Similar to Android. I don't like the private messaging system or polls that phpBB provides so I'll use different extensions that I like better. Or I don't want bbcode, I want markdown so I disable bbcode and install a mark down extension.
Instead of having to modify existing features to behave how I want I can drop in a whole new system.
Releases could be easier as well. The core wouldn't have to be updated very often once it becomes stable. Just release new versions of the extensions to add new features or fix bugs.
Instead of having to modify existing features to behave how I want I can drop in a whole new system.
Releases could be easier as well. The core wouldn't have to be updated very often once it becomes stable. Just release new versions of the extensions to add new features or fix bugs.
Eric
- Pony99CA
- Registered User
- Posts: 986
- Joined: Sun Feb 08, 2009 2:35 am
- Location: Hollister, CA
- Contact:
Re: Core vs. Extensions
I think that this is my original officially supported plug-in suggestion. Further posts in that topic give more suggestions.tmbackoff wrote:This was brought up some time ago by Steve (Pony99CA). If he sees this topic, I'm sure he'll dig it up and link to it.code reader wrote:ideally, the core should contain as little as possible, and a lot of functionality, that currently resides in "core" should really exist in extensions
I also espoused that suggestion in other topics, including the concept of a "phpBB 3.0 compatibility pack" of officially-supported extensions to compensate for any features removed from the core.
Steve
Silicon Valley Pocket PC (http://www.svpocketpc.com)
Creator of manage_bots and spoof_user (ask me)
Need hosting for a small forum with full cPanel & MySQL access? Contact me or PM me.
Creator of manage_bots and spoof_user (ask me)
Need hosting for a small forum with full cPanel & MySQL access? Contact me or PM me.
Re: Core vs. Extensions
Development model as in:code reader wrote:this is simply not true.VSE wrote: This basic development model is the same as it has always been since phpbb 2.
The developer team manages the development of the phpBB software (no matter who is writing/submitting code). Beyond that, MODs (extensions) and Styles that extend what the phpBB forum can look like and do are created by the community.
Has an irascible disposition.
-
- Registered User
- Posts: 653
- Joined: Wed Sep 21, 2005 3:01 pm
Re: Core vs. Extensions
(risking being called a nitpicker, i'll respond one more time):VSE wrote: ....
Development model as in:
The developer team manages the development of the phpBB software (no matter who is writing/submitting code). Beyond that, MODs (extensions) and Styles that extend what the phpBB forum can look like and do are created by the community.
i did not understand what you just said.
as mentioned above, Neil ("naderman") is part of the community since circa 2005, so he should remember the 2.0 "basic development model".
just ask him if he thinks this "basic development model" did not change since 2.0.
i will be very surprised if he agrees with your statement.
if you are familiar with eric s. raymond's seminal essay/book "The Cathedral and the Bazaar" (you might want to read at least the essay if you are not familiar with it), i think you'll agree that phpbb "basic development model" was strictly and purely in the "cathedral" camp in 2.0 days.
i hope you will also agree that it is almost completely in the "bazaar" camp now.
the switch from cvs/svn to git is both symbolic and practical representation of this shift.
peace.