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

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

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

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.

Quote:

This is the tact I will be taking when I am able to work on the modules. I am still swamped with stuff at home but hope to loosen up some time soon.

My intension is to modify the PM and Profile modules to provide majority of capacity of Yogurt. You will have to setup what you want but it will be accessible. My intension is to make it fully scalable and allow for lots of functions.

When I am up to speed on how XOOPS works development wise I expect to likely be rewriting large portions of both modules to make them highly flexible for things.

There will be support for saving things such as video and audio but you will need plugins to play them if you so desire. I will see whats available when I get to that point.

I will be monitoring other simular projects to see how they work but I have some ideas for some things that should make XOOPS capable of doing just about any sort of social network.

Will likely end up with a search module as well to provide a way to find users...

I will be looking for ways to make profiles skinable for the users and some other cool features. But I may not see a major break in my time available until June of this year so I will be at most tinkering with stuff and trying to learn how the system works...

I would be willing to help write documentation. This would help me learn some of the in and outs of XOOPS before moving on to other functions..

Who, what, where and when?

I can only speak english.

Quote:

Thanks for the site but I don't speak German and there was no translation link on that site that I saw. I could go through a universal translator I suppose but without downloadable code it won't do me much good anyhow at this point.

In response to JAVesey...

1. I am new here... Part of the reason for this message is to get some input like this... So thanks!

2. With the changes I hope to make I think I can create them in such a manner that they can add A LOT of power above and beyond what is there now BUT by default will NOT be in place. Thus you have the same functionality as you do now without added bloat but can expand well beyond the default if you need to without spending hours tracking down new modules. Initially they will obviously be alternative modules but due to the power they can add to a XOOPS site I believe they should be able to be added to the core package once perfected. That of course will depend on the call of the core devs and likely depend on me not stepping on anyones toes... Again a good reason for leaving this message instead of just writing code... XOOPS has come a long way since I heard of it from one of the original developers when it was just an Idea.. I hope to help out with this and potentially many other items as I learn the ins and outs of this software. I should come up to speed relatively quickly once I get the handle on a few more things.

3. I will look into this... THANKS!

4. I was under the understanding that the author of Yogurt pretty much washed his hands of that project and other people were taking up the "cause" since then. I will be following up on anything I can find out with this one...

Again thanks... I do not intend to step on anyones toes and I am using this as a learning experience to go from there.

At this time some of the items I will be looking to add to the PM module include support for winks, pop up windows, simple IM type chat, a way to check status of messages so you can include it in your site theme without having to use a block or pop up window to do so. Support for automatic trimming of messages older then x number of days without intervention by the admin if desired. Along with anything else required to make things work with the extended profiles module. This module will work without the extended profile module installed but certain features may not be available such as winks.

Due to the complexity of profiles this module will likely be eventually rewritten. Support for things such as profile pictures, favorites, friends, groups, search. Profile pictures will be allowed to be stored in the database or in a folder depending how the admin wishes to use them. I intend to create a way to make the profiles somewhat "skinable" by the admin and allow the admin to have a lot of flexibility in how to design the look of the profile pages, the search pages etc, I also hope to add a way to create "preferences" that will be used to do profile searches and such as well..

Looks like there will be a demand as well to export/import the user profiles which I will look into a responsible way to do this. XML is supposed to be a way to do this and I will look into a standardized format to do this instead of reinventing the wheel..

Ok so those are my ideas so far...
If you have anything else you can think of please respond and let me know...

I am currently working a lot of hours so this is not going to be a quick project.

The purpose of this message thread is to get ideas of features to add to the PM and Extended profiles modules. I intend to add the majority of functions found in Yogurt and related functions.

I am a "new" developer to XOOPS and have decided to take on a project of my own to learn how XOOPS works and how to program for it.

In the end this should benefit the XOOPS users and the intension is to change the mentioned modules and perhaps add another if necessary. As the modules evolve I would like to try getting them included with the core as the planned module rewrites will allow XOOPS to challenge pretty much any social sites to date.

This Thread is intended to get ideas for changes other then ones I already have in mind. I am in the planning stages of this and tinkering around with modules and such in general as I plan the changes.

Please reply if you have any suggestions of things you would like to see included in these modules.