A few years back when XOOPS was a thought that was being developed there was a plan to have support for "hooks" to the API for modules.

It has been a while and I haven't seen anything that refers to this so I wonder if it was a lost idea that never got developed.

In short...

You have the normal API which has a core set of functions. With modules you could add additional API functions that could be used by other programs but were apart of the modules.

As an example...
Without the PM module installed you would have no support for private messages in the system. However when you add the PM module you could not only directly make use of the PM module but other modules could use functions from the PM module so they would not have to be rewritten.

If this was not a function built into XOOPS by this time is it something that is being considered?

I also wonder if there is a way to speed up the rendering of Xoops.. Seems slow to me and it should be alot faster I would think.

Do you have any concrete design on the 'hook' system?

I will add, an observer pattern on users.
When users are deleted (or added or modified) a way to alert modules.

I am typing this from my phone so please excuse any typos etc.

I will expand upon this more when I get home but yes I have a very workable method that should work well.

please note that I have begun to refresh my php knowledge. it has been about 8 years since I developed in php so I am playing catchup and I haven't dived into the full structure of XOOPS yet so this is sort of shooting in the breeze.

I believe the only way you can provide for hooks is during the installation/upgrade stage of modules. any other method would slow the system dramatically.

You have a registration listing of the modules available and the functions they can provide to other functions including version number etc. the functions should be prefixed with the modules name to prevent clashing.

Think of how languages are associated and how translations are done. in your module 'install' directory you provide separate files that use specific routines based on what modules are already installed. during installation or upgrade the admin can choose which module setup to use. the install/upgrade script will then copy over the necissary files to the system and you have a specific module trimed down to use specific functions. there may need to be a dependency table also setup so that if something is updated the modules effected can be updated as well...

This system would work with the module system as is and allow for upgrades easily.

You might also be able to move some of the base system to modules or allow system api stuff to be replaced with modules as well. thus allowing easy upgrades or changes without releasing a whole new release for simple replacements.

The install scripts can thus be maintained off the htdocs folder for security purposes.

This could require major changes to core to support at the system level but could be attempted at the module level first to see how well it would work.

Clear as mud?

Again since this all happens at module install/upgrade time it should cause NO slowdown to the system in practice. Could also lead to great reduction in over all coding and potentially speed up things.

Rodney

Again, remember I have not gotten into the actual structure of XOOPS as of yet and suggesting based on information as I have it and assumptions at this point.

Another addition to the module structure which came to mind since my last message after thinking about the message posted by hervet would be to allow a method of allowing modules to tie into some functions and add their own. For instance, for a delete user function this might normally be an admin function of the Profile module. However if you needed to provide a deletion in other modules you may "tag" along so you can delete whatever data you may need for other modules.

Example, if you insall a profile module... It will have add and delete users...

If you add a social module that has its own data related to a user... You can then tag onto the add or delete functions of the profile module so that the social module also runs its delete user or add user functions when the profile module runs.(Simular to the old way we used to change boot up programs by changing the ofset in the boot up string to a new program and at the end of the new program it will jump to the original jump point where the boot process continues... Or you end up with a Que of functions instead of one simple function...)

Plus any other module that tags along.

This will be an addition that again would be done during module installation/upgrade in a manner simular to the method mentioned prior.

This should prevent the need for hacking core or modules to add functionality for other modules.

Rodney

Ok I am actually developing the whole idea of interdependencies amoung modules as I work this morning. But the main idea I can outline here...

You write a social module that requires a private message to be able to be sent out.

When you wrote the module you wrote it to be compatible with pm,( Versions 1.0, 2.0 and 3.0) as well as SuperPm (Versions 1 and 2 ) and lastly PmPlus (Versions 1, 2, 3). (These names are totally made up to prove a point...)

You have your functions related to sending private messages setup in seperate files, one for Pm, one for SuperPm, and PmPlus (assuming the versions for the same modules all provide the same functions we need). You also have a file setup that perhaps has a simple replacement in case none of the other modules is available.

When you install the module for the first time you have the pm, superpm, pmplus and default modules all in order of preference and check for a compatible version. Once selected the associated module file is included in the module to support which module you are using. (Lets assume SuperPM version 1 for this example.)

Ok now we upgrade SuperPM to version 2. This will check for dependencies before upgrading the module. It will warn us that our social module depends on this module for functionality but is compatible and if we continue the social module may be affected.

If we then upgraded to SuperPM version 3 it would check and figure out it is not a compatible version to our social module and warn us that we will need to upgrade our social module to maintain compatibility. If you continue then the social module would automatically become inactive until you do an "upgrade". (The compatibilities could be in the info file for the module. )

Also if you remove the SuperPm module it would warn of dependencies and if you continue it would deactivate the social module requiring you to Update the social module.

Lets say you removed the SuperPM module and now went to the PmPlus module, after it disabled the Social module and you install the PmPlus module and make sure it works you then can go back to your social module and do an upgrade or maybe update would be a better term to allow it to use the new module.

Does this make sense?

Since it is all done at the install/uninstall/upgrade module process it should not effect the usability of the system over all and require minimal downtime to upgrade.

The method to carry out all of this will become obvious to me when I actually have the time to dig through the source code and figure out how things are done. But you should get the main idea anyhow.

Rodney

What you are looking for is more or less already within the XOOPS structure, albeit not exactly down to the letter though.

There are 3 different on(install, update, uninstall) functions that the module installer/updater script look for when a module is installed or updated. These functions are module developer defined and can be anything from one line to a whole script. Basically these allow the developer of the module to do various tasks that they deem fit to do during this install/upgrade process.

So, in theory, you the developer could write a script to check which modules and versions are required for the proper running of your own module/s.

But if your interest in this area needs further information, I would suggest that you look at the code in

ROOT_PATH\modules\system\admin\modulesadmin\main.php and modulesadmin.php (the install and update and uninstall methods should show you the hook provided).

Also to see this in action, I suggest you look at some of the smart module and how the implemented their modules with these hooks.

I am more than sure that these method can be updated, modified or changed to enhance the features that are already there, and we are very open to your further suggestions :)

observer pattern was added to XOOPS ORM class, however for the concern of performance, it is not recommended.

Use a hash 'table' that maintains independence suggested by redheadedrod could be a solution.

After further thought on this, I do agree that with the current system individual developers can do something like this and you end up with module systems like the "smart" ones or other ones like the "altsys" stuff. However...

I believe if you standardize a way to do this it makes things easier for everyone because I know as a developer I don't want to remake every wheel or copy someone elses code when I do something with a module. Or depend on someone having a particular module installed to make mine work. But if I can allow a module I make work better by using other modules and do so easily then I think it is a good thing. There is no reason this couldn't work much like how the Language system works for translation.

You could definitely use a hash table to list the available routines to use. If defined flexible enough this could be used also to provide for unique options with the modules as well. One such item could be the simple add/remove users item as listed above. The profile module could look for other modules that have a "delete user" or "add user" function that need to be run along with the one from the profile module and yet do so in a way that doesn't require hacking of the original profile module. But I envision still a system that would be used during the install/upgrade/uninstall cycle and not during normal use to prevent a performance hit.

Perhaps a table for interconnected functions such as the one listed here and another for the module "offerings" and dependencies.

I STRONGLY believe after much thought that this is something that should be dealt with when modules are installed/upgraded or uninstalled. I would have to believe if it is done at that time any performance hits should be negated since when you get done installing the module the modules installed should operate no differently then normal modules do now. All of the work is done by the admin and only the end result is seen by the users.

The xoops_version file could have a "dependency" field added and go from there. You could support having different combinations of dependencies by having each line list all the dependencies for that module. (Ie if you could use 1 module or a combo of two modules then you would have the first line list the single module and the second line have the other two modules listed. Thus you can satisfy the dependency with either line being satisfied)

A new Module could be developed to handle the dependencies etc. I envision a module that would work much like the dpkg utility under Ubuntu to handle this stuff. Where you use the utility to install the modules, check for dependencies and activate or deactivate modules as necessary based on dependencies.

My intent with this project overall is that as I get up to speed with PHP and how XOOPS is put together I will help out with trying to improve the flexibility and scalability of this system. In doing so I learn the ins and outs of how the system works and can help build a better system for my own stuff as well. I am outlining a unique dating/social site at this point and no one is doing anything close to what I am doing. Flexible, fast software is needed to run what I want to do and by helping develop XOOPS into a better system MY site will be that much better then anything currently available. I only mention this so you understand my motivation.


Anyhow enough grandstanding for one day, I hope this is something useful and I am off to go play with source code and start figuring out some things.

Rodney