It's not a MOD, it's a feature package

General discussion of development ideas and the approaches taken in the 3.x branch of phpBB. The current feature release of phpBB 3 is 3.3/Proteus.
Forum rules
Please do not post support questions regarding installing, updating, or upgrading phpBB 3.3.x. If you need support for phpBB 3.3.x please visit the 3.3.x Support Forum on phpbb.com.

If you have questions regarding writing extensions please post in Extension Writers Discussion to receive proper guidance from our staff and community.
Post Reply
Bycoja
Registered User
Posts: 2
Joined: Tue Jun 22, 2010 7:34 pm

It's not a MOD, it's a feature package

Post by Bycoja »

Hi everyone,
as I'm not so much into the current development of 3.1, I'll just barge in with my idea.

As a MOD author I often struggle with the features my MODs offer. One the hand, I would like to follow the kiss rule (keep it sweet and simple) and don't include too many options. On the other hand, I try to consider the user's feedback which results in more features almost inevitably and comes along with higher memory usage, additional database queries, more required space, etc.
This bloats the mod with a lot of features which might be useful for some people, but even more useless for others (how surprising, huh?) thus increasing the need for a more flexible mod integration in order to avoid the problems of having features you don't necessarily need. What I was thinking of at this point is to replace the current "sink or swim" mod system with feature packages. Especially with AutoMOD users could easily choose which features of a mod they like and which ones they don't want to have when installing the mod - just unselect these.

For instance, if you went to buy the ingredient in order to cook a tomato soup, you would have a basic idea in mind of what you will need (guess what?) - that's the slim core of our feature package defining what the mod is about in a really basic way. However, if you wanted to make your soup taste good, you would need some additional stuff like spice, an onion and cream (forecasting complains about the recipe here!).
If you hate onion/a feature, you can just leave it out as the core of our package will still work. However, while some features will work without any other code, others will refer to the core or another feature obviously leading to the need of dependencies, which tell you what is required to install a particular feature.

How would this idea look practically? Well, first of all there should be a built-in AutoMOD handling the features and providing a consistent intallation interface, which allows you to browse the feature package, install and uninstall single features even after the core has been installed - not a big deal as AutoMOD stores the mod anyway. As for MODX I thought of having a structure very similar to the current one with the difference that instead of having a lot of changes for the whole mod, the install.xml would consist of grouped changes referring to a particular feature.

Instead of looking like this

Code: Select all

<action-group>
	<open>
		<edit>
			<find></find>
			<action></action>
		</edit>
	</open>
	<open>
		<edit>
			<find></find>
			<action></action>
		</edit>
	</open>
</action-group>
the modx files would be more like that:

Code: Select all

<core>
	<open>
		<edit>
			<find></find>
			<action></action>
		</edit>
	</open>
</core>
<feature-list>
	<feature name="first_feature">
		<open>
			<edit>
				<find></find>
				<action></action>
			</edit>
		</open>
		<open>
			<edit>
				<find></find>
				<action></action>
			</edit>
		</open>
	</feature>
	<feature name="second_feature">
		<dependency>core</dependency>
		<open>
			<edit>
				<find></find>
				<action></action>
			</edit>
		</open>
	</feature>
</feature-list>

FeyFre
Registered User
Posts: 29
Joined: Wed Mar 17, 2010 9:49 pm

Re: It's not a MOD, it's a feature package

Post by FeyFre »

Bycoja wrote:As for MODX I thought of having a structure very similar to the current one with the difference that instead of having a lot of changes for the whole mod, the install.xml would consist of grouped changes referring to a particular feature.
Bycoja, I have analysed your post.
So your suggestion formally is manifest for other MOD developers to make release of their MODs as group of independent features-packs, which possible have common core. Possible you are right. But it is choice of MOD developers, not PHPBB Team or PHPBB users. Current specification allows MOD developers to do that(possible there are missing some invaluable details, like dependency system).
(Yes, MODX system is more powerful than most of us can image)

So I think your post will be more efficient if you place it on more suitable place, for instance here http://www.phpbb.com/community/viewforum.php?f=71
Last edited by FeyFre on Thu Jun 24, 2010 8:25 am, edited 1 time in total.

Bycoja
Registered User
Posts: 2
Joined: Tue Jun 22, 2010 7:34 pm

Re: It's not a MOD, it's a feature package

Post by Bycoja »

FeyFre wrote:But it is choice of MODX developers, not PHPBB Team or PHPBB users.
MODX is being developed by the phpBB team in fact.

FeyFre
Registered User
Posts: 29
Joined: Wed Mar 17, 2010 9:49 pm

Re: It's not a MOD, it's a feature package

Post by FeyFre »

Bycoja wrote:MODX is being developed by the phpBB team in fact.
So what? Does it unusable? Does it restricts MOD authors?
MODX specification already meets all requirements you mentioned in your post. So problem not in MODX specification, and not in people who created it.
Each MOD author chooses own MODX usage manner. One author can ctreate one huge MODX, which adds a dozen of features, other author can create a dozen of tiny MODX for each feature.
MODX is method(container) to deliver feature from MOD author to end user.
Diff/Patch is other method to do it.
Verbal description of changes in plain text file is yet another method to do it.
They responsible only for delivering of features. They must no be, and never will be responsible for feature usage, development, classification etc, because this responsibility lays on MOD authors. So this question is for MOD author, not for MODX authors.

igorw
Registered User
Posts: 500
Joined: Thu Jan 04, 2007 11:47 pm

Re: It's not a MOD, it's a feature package

Post by igorw »

Bycoja wrote:Well, first of all there should be a built-in AutoMOD handling the features and providing a consistent intallation interface
Yup, and this is planned.
Bycoja wrote:As for MODX I thought of having a structure very similar to the current one with the difference that instead of having a lot of changes for the whole mod, the install.xml would consist of grouped changes referring to a particular feature.
I agree with FeyFre here. MODX already offers this. Instead of making the XML even more complicated you can just create a separate MOD package for each sub-feature and specify a dependency in the author notes / description.

User avatar
DavidIQ
Customisations Team Leader
Customisations Team Leader
Posts: 1904
Joined: Thu Mar 02, 2006 4:29 pm
Location: Earth
Contact:

Re: It's not a MOD, it's a feature package

Post by DavidIQ »

eviL3 wrote:
Bycoja wrote:As for MODX I thought of having a structure very similar to the current one with the difference that instead of having a lot of changes for the whole mod, the install.xml would consist of grouped changes referring to a particular feature.
I agree with FeyFre here. MODX already offers this. Instead of making the XML even more complicated you can just create a separate MOD package for each sub-feature and specify a dependency in the author notes / description.
Definitely agree. The last thing we want to do is make MODX any more complicated than what it is right now :?
Image

sajaki
Registered User
Posts: 86
Joined: Mon Jun 21, 2010 8:28 pm

Re: It's not a MOD, it's a feature package

Post by sajaki »

Bycoja wrote:Hi everyone,
as I'm not so much into the current development of 3.1, I'll just barge in with my idea.

As a MOD author I often struggle with the features my MODs offer. One the hand, I would like to follow the kiss rule (keep it sweet and simple) and don't include too many options. On the other hand, I try to consider the user's feedback which results in more features almost inevitably and comes along with higher memory usage, additional database queries, more required space, etc.
i've received requests like these aswell. i usually just say "no", because we want to be flexible so we publish feature x as a plugin. This plugin implementing feature x is just written as a "mod on a mod", so i make heavy use of the dependency tag :

Code: Select all

<link-group>
 <link type="dependency" href="" lang="en"></link>
</link-group>
On the UMIL side i have a check if there is a $config entry for the dependent mod, and trigger an error if it isn't there. But your approach to extend the dependency tag to include features "within one mod" (if i understood that right), is really interesting.

Post Reply