[Phpslash-devel] A question / proposal for further extenting phpslash's modularity

[Thanasis P. <ba...@ey...>]

   Hello there,

   I would like to make a question and furthermore a suggestion for phpslash.

   I am a small webdesign's company general manager and the lead programmer 
for a big web project which offers a variety of services to the IRC 
community. I will talk about the web project, the company info is 
irrelevant, but to your disposition if you want it. (the company's url is: 
http://exta.gr)

    At this point the project is in release candidate mode and we are 
scheduling for an official public release at about 1st June 2002. 
Describing the various features and services of our project would be out of 
topic, you may get a picture if you visit http://eyersee.org

   I will take for granted that you have basic irc knowledge (who doesn't) ;)

   There you will notice a slash like engine. The engine is doins, i will 
talk about it later.

   Before i ask my question i would like to introduce you to some core 
features our project has, so that you may understand completely the nature 
of our 'problem' . The eyersee engine has it's own user database and 
authentication system so that it meets it's purpose (offering services for 
generic irc users and channels). We also have a security levelling system 
based on modules (the services) for users. The security levelling system is 
based on user id, the module (service), the access level and the (irc) 
channel this access applies to.

   Our engine allows irc channels to register freely and creates a unique 
url for each channel based on its name and network. Each channel that 
registers gets its own services customized and has full administration 
control over them. A very good example is our sample - beta testing channel 
#hellas. You may visit the url: http://hellas.und.eyersee.org to see what i 
am talking about. In this way, any channel may have its own url and 
services. (you may check the full services we offer in our faq).

   One of our developing rules is keeping a uniformity throughout the whole 
website regarding user accounts/sessions and their access levels. This 
means that a users logins *once* and may operate on any of the varying 
services our website offers.
   This forces us to rip down packages to meet our needs like the phpBB 
forum which we patched to recognize our user authentication system, instead 
of the one it had pre installed, and levels authorization, so channel 
managers and privileged users may manage these services. You understand 
that we prefer to rip down ready made packages instead of having to write 
them down from the start so that we can focus in the core engine of the 
eyersee (channel/user services).

   This fact (ripping) has a major good point and a major bad one. The good 
point is time gaining. The bad point is that by the time we rip, we are on 
our own for any further development of the service we ripped, since such a 
type of hacking does not allow any upgrades to newer releases of the 
services that the teams publish.

   When we came down to think what package we should use for the main 
eyersee.org website (a slashlike engine was the need), i parsed through all 
the packages i was able to find through the freshmeat / sourceforge search 
engines. My criteria was that the engine should be in php so that all our 
core classes would be operable and useful.

   The best package i came across to was ofcourse phpslash :).

   I downloaded and started reading the code so that i would understand 
where to inject snippets of code and what to rip and how (headers/footers / 
sidebars/ auth system).

   It wasn't something easy, i consumed many times experimenting on various 
approaches on how to hack the code so that it would meet our requirements, 
but there was a main drawback.  There are no classes handling user's 
sessions / ways of displaying users other but phplib's. This as a fact only 
gave me one choice, rip any code that refers to users for  authentication, 
displaying or management in order to make it work for us.

   This was not possible without loosing any possibility of further 
upgrading phpslash with newer releases, and as i observed the one i was 
working on (0.6.2) was not such a final release of what you have in your 
minds to accomplish. So we came across this dilemma, to what to do.

   Hopefully in my desperation for an urgent release on a slash like engine 
i  came across doins. Doins is a very simplified clone of the slash engine, 
and was able to rip it down in less than a day. Ofcourse the services it 
provides are primitive and basic. This is not what we would like to have as 
our main news board.

   In general what i have observed is that if you want to have a slash like 
engine and keep up to date with new releases, you must in no way touch the 
code, or if you do, you should note down what you have changed so that you 
change it again in the next release. This comes handy for sites whose only 
interest is presenting a news board for specific matters and adopt the 
phpslash's user authentication system and general content presentation 
wayis as their website's core structure. But this fact is really a pain in 
the ass for websites wanting to embed such services in the infrastructure 
they already have.

   The question/suggestion i want to make is whether you are interested in 
making phpslash more embeddable to sites. I believe it would be a unique 
feature for a package, since it would allow major site managers to easily 
install phpslash to their site, maintain their user/auth subsystems and be 
able to upgrade to newer releases of the package.

   This can be achieved by 'wrapping' classes to phplib. A short example 
would be having a users class that will handle all user interactions to the 
engine, authentication, session registering, access levels, displaying and 
more. So that each time someone wants to printout the name of the author of 
an article would call the user object to do it for him. This would apply as 
a global rule for the whole engine and will have as a result the easiness 
of embedding the engine in other user/levelling concepts. The webmaster 
would only have to rip down the users related classes and get ready. Why I 
make such a fuss about how the users are displayed? Because as you might 
notice in our project, we have a unique way of displaying user info and the 
whole projects (eyersee's) concept is heavily relying on this fact. That 
is, we want each user's information box to be displayed wherever his/her 
nick is mentioned throughout our website(s).

   I would like to state that we (the developers of eyersee) are willing to 
take this assignment so that both projects (eyersee and phpslash) will 
gain. Ofcourse we will see so that nothing is broken from the functionality 
already exists in phpslash, and furthermore extend the user/ levelling 
functionality.

   We have a ready plan on implementation about this (since the eyersee 
engine is build upon this logic) along with ready classes that will speed 
up this work process. Your help ofcourse on various aspects of your 
projects guidelines is more than needed :)

   Thank you for the time you've spent reading this post, and excuse my 
english as im not a native english speaker :)

   Waiting for your reply and comments, and ofcourse i understand that many 
topics where not covered. But i believe everything is explainable over 
discussion, so that i wont have to post now an 80 page pdf explaining :)


     babbos