Today there are a lot of great modules for Xoops2. Overall quality may vary from one to another, but they all solve reallife problems pretty well. The XOOPS core modules and classes are well designed and deserve recognition.
When a module developer starts coding, he has little documentation on how to develop his module and what are the best way to access the database, manage user permissions, store files, use notification system,... So he often starts from an existing module "similar" to the one he wants to develop. This is a good way to propagate best practices but also the worst ones...
Beside the propagation problem mentionned above, a lot of modules are doing identical things in different ways (file storage, image management, etc.). This is a huge waste of time for module developers and an error prone process. Furthermore it prevents the development of common behaviors between different modules or any kind of loose-coupled interoperability between modules.
In order to bring XOOPS to the next step, lets say the enterprise one, XOOPS needs a strong module development framework that will allow the construction of robust, extensible and interoperable modules. This implies at least 3 things:
- fully document the current core XOOPS framework
- identify common core module components
- develop, document and promote these new additions
I think the current organisation of the XOOPS team is perfect for supporting this. The Core or module team for development, the Documentation team for documenting the framework classes and the Quality Control team could ensure that new modules are "Xoops standard compliant".
IMHO, here are the most important things that the module developement framework should deal with.
1. Authentication
2. File management
3. Database abstraction
4. Simple Workflow engine
A new "team workspace" module could be developed in parallel to test and implement the framework under construction.
1. Database abstraction layer
Even if MySQL is and should stay the default database for Xoops, a database abstraction layer might be useful. The small performance cost of adding this abstraction layer ("never write a SQL statement anymore") should be nothing compared to potential architectural advantages. What about if MySQL guys introduce new way of writing queries, optimizing it or improving search mechanisms ? Let's the XOOPS user decide the database he wants to use. Just implement the MySQL classes. What about fulltext search in MySQL that is almost unique ? The interface should provide a search method. MySQL implementation will be easy to write and other database implementations will use proprietary mechanisms to achieve the same results. But this is not the XOOPS problem
(see pear or ADO)
2. Authentication abstraction layer
The process of authenticating a user should be completely externalized and pluggable. We should be able to select the implementation that best suits our needs. A good way to follow is PAM or JAAS (an implementation of PAM in Java). A chain of loginModules implementation is the core of such a system. We should not have to hack core files anymore to adapt the authentication mechanism...
3. Filsesystem abstraction layer
The framework should provide an abstraction layer to store and retrieve files (either in the hosting filesystem or in the database). Every users and modules should receive a dedicated (private) space through this interface. The access rights should be based on the standard user/group XOOPS security classes. This would allow to build, for instance, common GUI components to store and retrieve files reusable throughout all modules or a Personal Web Folder to store and organise private files. All direct access to the filesystem should be prohibited. This could become the core of a real Document Content Management system: you could add metadata support, indexing, trigger workflows/indexing/process/etc., etc.
4. Simple workflow engine
Every objects have a lifecycle. Lifecycles may be very simple or very complex. They may need to be persisted or are just volatile. Let's imagine: when needed, you define a UML State diagram for your "stateful" object with your favorite tools. You export it to XMI and load it into your XOOPS Workflow engine. Don't forget to tell the engine if you need to persist the object states or not. That's all. You have completely externalize the workflow of your application. When you want to get/set the state of an object just send the approriate event to the Workflow engine... Am I dreaming ? This is already done by some frameworks... This kind of engine could greatly help in building more complex document approval flow (ex. FAQ, news, Articles, etc.) and open a lot of new doors for modules developers. Workflow engine is perhaps the most difficult part of the framework to design but it might be its greatest strongness.
5. OK, I won't talk to you about asynchronous messaging (MoM) ... today !
I am convinced that many things have already been done in the Free and Open Source world to help XOOPS building such a framework in a reasonnable timeframe.
The architecture of an Information System is more important than its source code availability. Even with the source code available some things can be impossible to realize due to a bad initial architecture. A good architecture should ease the participation and collaboration of modules developers. And the XOOPS authors have understood that from the early days. It is time to build a first class developer framework on top of the good core. This framework should also improve data reusibility. New modules and services will follow accordingly. If XOOPS succeed in it, it will really become the best Free CMS based on PHP and will have its place in the enterprise.
Now, let's start the discussion !
Benoit
