As a module developer I am concerned at the lack of any real concern regarding the direction that the council seem to be taking with this area of Xoops. As many of you know I have given many years to XOOPS with my own modules, helping other module developers and creating dev.xoops.org and a module development team. The out come of the later has helped produce many of the modules that some people use daily.

While the current thinking is that this area should be left to the community to run, I personally think this is not the way that module development should be handled.

We have all seen the demise of any real activity in this area over the last few years and it is steadily getting progressively worse and will continue to do so and if we do not act now, the situation may become to vast a gulf to actually be fixed.

Xoops does need a module repository and now it is even more of a need for a developers working area. Very much in the same method that Joomla has for their component and module developers. This platform (if run correctly) would provide valuable resource not only for module developers but for the core as well, as many of you know I believe that core development and module development should work closely together at every possible stage. Mainly due to the fact that both area’s push forward development with new ideas, bug fixes and security issues.

If there is any doubt why we shouldn’t be doing this, then I would say that the current consensus within the community would be the deciding factor. You just need to look around with these forums to see that people are not happy and confused by many issues surrounding the usage of modules.

1. Security: This is a very important issue and is not being addressed properly. If a security issue arises with a module many people are unsure who to contact and who is actually responsible for the modules development. Many of the previous core modules are now so out of date and not actually secure, but they are not actually actively developed or maintained by anyone within the community. Agreed, we have a few development houses that actively maintain their own modules but what if the stop?
2. Compatibility: It has been reported that many of the modules in circulation are now not compatible with the latest version of XOOPS (actually this has been since 2.14) and the gulf between older modules and the newer core will only continue.
3. Workability: Many modules now actually are a few years old, they are out of date and do not confirm to standards. With no one actively updating older core modules, newer features and other important updates (i.e. conforming to the core standards and newer core additions) are not implemented and this decreases not only the workability of many modules but actually makes many of the key core functions redundant in many respects.
4. Support and Development: This to me is the most vital aspect of module development and for many different reasons. Actively developed modules are vital to the community. No point in having a Rolls Royce fitted with a 2 piston engine. In essence this is where we are heading. Yes we do have Smart modules, we do have Instant-zero and a few other developers continually working on their own without the backing or resources that should be provided to them by the core. If these main developers decide to stop working in the XOOPS community, there would be a crisis and a big short fall of modules within this project.

If there is any doubt that this would work, I need only remind some people of the importance and the reason why this should be actively committed too the core as part of the core as part of the module development area and run by committed developers for the future of the project.

My suggestion would be to establish a module development team to work on key core modules working in synch with the core developers but not as a community driven department. This as already degraded module development standards within this project and fragmented module developers. We need a platform for standards, direction and development issues currently not addressed in the last 3 years.

I again ask you to reconsider dev.xoops.org and ask that this area be given the resources and man power to be run correctly.

I agree with the idea of keeping a module development area like dev.xoops.org where module developers can maintain their modules and keep track of versions, bugs, feature requests etc.

The dev.xoops.org site is down at the moment by the way, I hope this is just due to temporarily maintenance? I did not have time to keep track of all the recent debates going on about the site changes etc.

Best regards,

wtravel

Quote:
So do I but .....
1/ The first time this site was hacked, we had to reinstall everything (our modules) because "there was no backup"
2/ The second time (now), they don't have the keys ....

Quote:

There has been very little information regarding this issue than it's been hacked and who has the keys issue. It would be nice to actually have some information or talk regarding this issue. This subject is very important to the community and for the future development Of Xoops.

I hope that this discussion does not get lost due to the other issues and people will voice their position or concerns regarding this and not let and central module development area die the way it seems to be doing.

Catz

Who is working on fixing the module dev right now?

As really if we are going to make it what we need as a few of us have been discussing via IM………. Then it needs making into a full module repository and fixing centre in one go…it doesn’t need to be as it was before, yet refined loads to make it much better:::

1) A full repository for all our modules (hosting files on the server that the Foundation owns for us) + maybe using Sourceforge as backup to clean up the system and keep all items in one place.

2) Much more functional error reporting system and commenting for us to use on development and discussions for improvement (releases on the News can then be for glory and not as an error reporting system).

3) Clean and easier management system as to act as a full repository (each item from this point can have a description like before, yet more interactive where items get fixed and bugs and patches are easily submitted……. and not when you ask, you are told to wait and find the original author….fixes are there to improve user functionality for all and sometimes module authors are no longer around to ask.

4) Clear and informative up to date manual and development guidelines for incorporation of modules into the XOOPS system…now though this could be on a XOOPS Wiki, it needs direct linking in one place (so people can post and then edit code for improvements before acceptance into either module or core).

5) SVN copy of modules built in as to see latest development and fixes implemented into a working module, which can then be downloaded directly by any user.

Anyways loads more on this wish list, yet if we aim this way rather then backwards anymore, then perhaps we might get some work done around here….

i vote for pred+catz+other experts to solve the issue, on a new server, with the keys. Then to define the module dev needs so that the core team will be able to define a due roadmap with their inputs and designer's as well (other's as well), in a bottum up approach.