General Principles

[code reader]

The post below is going to be lengthy.
Also, i intend to return and edit it, as (hopefully) people will response.
this represents my thinking, not some absolute truth.


Chapter 1: What should be kept?
One of the important decisions should be, what parts of the existing system we like and should be kept?
The way I see it, here are (some of) the parts of current system worth preserving:

1. SubBlue. strictly speaking, of course, SubBlue is not part of the exiting system. however, his clean, streamlined and beautiful design is probably the one single thing that sets phpbb apart more than anything else. twisi, retaining Subblue for future versions is key to the success of phpbb.
2. dbal: Currently, phpbb supports probably more DB backend than any other bbs. there might be places dbal can be extended, streamlined, polished etc., but in general, it has proven itself so far, so we should keep (and nurture) it.
   one small comment, though: if we think the backup/restore system should truly be part of phpbb, dbal should support it better. as it is now, the backup/restore has a lot of "if mysql/if posstgres" which it shouldn't.

   Only thing I'd like to say something about is the dbal. I would like to investigate the option of using a proper ORM to finally get rid of SQL in frontend code. The current DBAL works pretty well as an underlying mechanism, but it doesn't support things like prepared statements. Doctrine seems like the best available ORM choice in the PHP world. We should certainly take the lessons we learned from building our own DBAL with us. We should then extend Doctrine to support all the DBMS we currently support.

3. the templating system.again, it can endure some adding of features and whatnot, but in general it's a good system that should stay.

Principle #1: Everything is Custom
Currently we have two features that support "Custom": Custom user fields, and Custom bbcode.
in both cases the "Custom" part is an afterthought that was slapped on top of an existing system, so the code support large number of user fields and large number of bbcodes "in the core", and on top of that the custom user fields and bbcodes.
this is not as should be.
all existing bbcodes and almost all existing user fields should migrate under the "custom" part ("custom" is not a good name, IMO. maybe "expendable"?).
if the current "custom" system is not strong enough to support them (e.g., i can't see how the URL bbcode can be supported with current capabilities of the "custom bbcode" system), then the "custom" part should be developed and expanded to the point it supports all the needs of the system.
there should be no distinction between bbcodes that are part of the core system and bbcodes which the user added. there should be no distinction between user fields and custom user fields (except, maybe three or four most basic ones, say user ID, user type, and maybe password and nick)


Principle #2: Everything is a plugin
I doubt that many would argue against the assertion that a top-rate plugin system is a must.
(i hope, some time in the near future, to post another post with the outline of the plugin system *as i see it*)
i want to stretch this a little bit:
IMO, as many of the core features as practical should be implemented as plugins.
this has several advantages: first, it keep us honest about supporting strong plugin infrastructure: if the core developrs will have to jump through the same hoops in order to implement a feature, they will surely notice every kink and annoyance in the plugin infrastructure and will fix it.
this will also give a (somewhat) unified management interface: the "on/off" switch for a built-in feature will behave *exactly* as the on/off switch for a plugin, because the built-in feature *is* a plugin.
it will also make it very easy to promote good user-contributions into the core: it basically becomes a question of packaging and nothing else. once you package a specific plugin in the basic install, it becomes "core"


Principle #3: User selections come on top of the system, not replacing parts of it
the only example i have ATM is the "edit style" disaster which replaces existing css files instead of augmenting them.
this makes upgrades a nightmare, users lose their changes, and tears aplenty for everyone.
the "C" in CSS is cascading, which, as far as i understand the term, means that you can define the same thing multiple times and the latest one is the one to be used. users style choices should be kept in a separate CSS file, to be loaded *last*.


Principle #4: Good, sturdy and well-define API is a must
i do not know if i have to expand this assertion - it is kinda sorta obvious.
every service any plugin receives from the system (e.g., the plugin may want to ask the system: "is this user allowed to do X?", or, "what is the value of user-field Y?" etc.) is an API.


as stated above, i plan to revisit this post and add and edit stuff, based on new ideas i might have and on readers feedback.

peace.

[ckwalsh]

This seems like it would be a lot better as multiple posts, so each item could be discussed

[code reader]

thanks.
i do plan to expand -*some* of these in separate posts, but not necessarily all.
for instance, if you agree to the principle "there are no distinction between 'custom' and 'not custom' bbcodes", it means that the "custom bbcode" system (which should be re-branded as "the bbcode system") need to be extended to support *at least* all the existing bbcodes, and probably in somewhat more generic manner that would allow all kinds of stuff.
i plan to try and outline such a system in a separate post.
(if i fail to do so, it does not necessarily mean this principle is wrong, it will just be a failure on my side to deliver)
stay tuned....


peace.

[bolverk]

This seems like it would be a lot better as multiple posts, so each item could be discussed

+1

dbal: Currently, phpbb supports probably more DB backend than any other bbs. there might be places dbal can be extended, streamlined, polished etc., but in general, it has proven itself so far, so we should keep (and nurture) it.

I actually think phpBB needs to gather some usage data and find out just what percentage of its user base is running on each db backend and look at the market trends in general. Trying to provide an abstraction layer for every db imaginable is a noble effort but not without it's negatives and just like browser support, you have to draw the line somewhere.

[ckwalsh]

dbal: Currently, phpbb supports probably more DB backend than any other bbs. there might be places dbal can be extended, streamlined, polished etc., but in general, it has proven itself so far, so we should keep (and nurture) it.

I actually think phpBB needs to gather some usage data and find out just what percentage of its user base is running on each db backend and look at the market trends in general. Trying to provide an abstraction layer for every db imaginable is a noble effort but not without it's negatives and just like browser support, you have to draw the line somewhere.

But that also sets it apart from other packages, in that almost anyone in almost any server arrangement can run phpBB.

It was mentioned on the wiki that the Doctrine ORM/DBAL might be used, and it already supports most of the database backends. Perhaps phpBB could help provide the rest.

Edited as I accidentally said Symfony instead of doctrine

[code reader]

I actually think phpBB needs to gather some usage data and find out just what percentage of its user base is running on each db backend and look at the market trends in general. Trying to provide an abstraction layer for every db imaginable is a noble effort but not without it's negatives and just like browser support, you have to draw the line somewhere.

i would agree if we were discussing adding a new backend to the mix.
however, i do think that we should keep alive all the currently supported stuff. the overhead, as far as i can see is extremely low, and it's exactly the kind of stuff you want from the core/infrastructure.

one thing that *can* probably go away is the ungodly "utf/data" monstrosity.
iiuc, most of it is there to facilitate migration from isoXXXX encodings. if migration from non-utf8 system is required, this should be in the realm of migration/migration tools and not part of the core system.

there may be parts of it i do not understand, but the goal should be, IMO, to use php built-in tools to deal with utf8, and provide the thinnest possible layer (ideally nothing) on top of it where necessary.

peace.

[naderman]

I agree with pretty much all of what you wrote in your original post. Only thing I'd like to say something about is the dbal. I would like to investigate the option of using a proper ORM to finally get rid of SQL in frontend code. The current DBAL works pretty well as an underlying mechanism, but it doesn't support things like prepared statements. Doctrine seems like the best available ORM choice in the PHP world. We should certainly take the lessons we learned from building our own DBAL with us. We should then extend Doctrine to support all the DBMS we currently support.

Oh and please go ahead and edit those principles into the wiki please. I'm sure things will get lost in these discussions the more people write in this forum

Edit: Oh and one other thing, we should keep an open mind on things like the templating, if something better than ours comes along, why not use it.

[code reader]

i agree with you on both points:
if a nice OS package is available that does what dbal does, i think we should ride their coattails as much as possible.

same goes for templating, but here i have a small reservation:
IMO, by far the most significant source of phpbb phenomenal success is the stylers/modders/translators community.
i do not think there is a question of keeping phpbb4 backword compatible with 3, but keeping the templates interface as similar as possible to the existing one is highly desired if you want to avoid *beep*-off the stylers.
it is "legal" to force them to learn a new "language", but i would not do so without some very real and pronounced advantages.
the template engine have not been a huge resource drain: it is extremely stable, and went though little change in the past several years, so replacing it only makes sense if some very real advantages can be realized.

as to wikization of original post:
i did not think it carried that much weight, but if you think so, i'll do it.
however, i'll appreciate some pointers/suggestions as to where exactly in the wiki this fits best.


thanks,
peace.

[naderman]

same goes for templating, but here i have a small reservation:
IMO, by far the most significant source of phpbb phenomenal success is the stylers/modders/translators community.
i do not think there is a question of keeping phpbb4 backword compatible with 3, but keeping the templates interface as similar as possible to the existing one is highly desired if you want to avoid *beep*-off the stylers.
it is "legal" to force them to learn a new "language", but i would not do so without some very real and pronounced advantages.
the template engine have not been a huge resource drain: it is extremely stable, and went though little change in the past several years, so replacing it only makes sense if some very real advantages can be realized.

I mostly agree with this. I was actually thinking of using a different implementation of the same templating language with a few additional features. One option I'm pondering is using the new symfony templating component. The goal should be to simplify things a bit more and add a few more features while basically sticking to the way things work now.

as to wikization of original post:
i did not think it carried that much weight, but if you think so, i'll do it.
however, i'll appreciate some pointers/suggestions as to where exactly in the wiki this fits best.

Well I'm not sure myself. I guess there's no need to create a page with all of what you posted here but some of those points could certainly be worked into http://wiki.phpbb.com/PhpBB4/Programming and http://wiki.phpbb.com/PhpBB4/Architecture. Maybe create a new plugins page to discuss extensibility and the plugin interface. I wasn't really sure about the page layout to begin with so if you feel like something should be organised differently go ahead and change it I figured we should start by collecting information in the wiki and then decide out how to better organise everything later or along the way.

[code reader]

i tend to think of anything inside the wiki as "within consensus" rather than "under discussion"
my thinking was to start a new "plugin - in depth" thread, and if/when a consensus begin to crystallize, this is the point to begin building the wiki.

peace.