XOOPS4 / XooSphere Development Roadmap

XOOPS 4.0 “Xoosphere” development roadmap v1


During the last years, a lot of people have been looking at the web differently, and showing the will to use more advanced tools. As such, the number of users subscribed to have been multiplied by X. And if the XOOPS community has grown in number, it has also grown in diversity.

Last year, when we realized that the XOOPS project wasn’t organized to handle so many people, we also had to admit that the XOOPS core architecture wasn't able to evolve as people wanted. Not so long ago, this program was just a php portal system, not even partly Object-Oriented as it is today, and made in an almost monotheistic manner. For the users, the enhancements added to XOOPS then XOOPS 2 have been quite positive, but for developers this legacy has been pulling us down. It has become harder and harder to contribute to the core, and to fix some problems, and it was time for a new start. Several other reasons were also convincing us that, if that had to happen, it had to be right now: PHP5 is already here, has great features, and one day we’ll have to decide to exploit them and forget about PHP4. Considering the re-architecure we plan will require several months, it was best for us to do this switch right now. We cannot ask developers to change their methods like this every year.

Shaping the Xoosphere

Across the years, the XOOPS core has evolved to become more than just a portal script. Hovever as of today it cannot be seen as a real Content Management System neither as an applications framework, while in the meantime it is a bit of all of this. For this reason, people have become unable to define what was XOOPS, and it was the first problem we had to solve before trying to go anywhere.

So we first tried to design a global architecture that could be able to integrate all the required components we could already imagine. The objective here was not to list all these components or to detail their individual implementation, but to give an overall unrestrictive structure to our future system mainly describing how its composing parts will relate to each others, giving a precise place to each of them.

Once its first layers implemented, starting from the lowest ones, this global architecture will be enhanced, detailed, grow to include new classes and frameworks until we reach our final objective: have a platform that will allow us to run and maintain all the web sites as we would like them to be (while they are actually too much built around XOOPS and its limitations).

At first, the Xoosphere project is about a way more than it is about a particular program or features:

  • We will take care of the way our code is built, enforcing design principles such as simplicity (not ease of use, which is something different), and modularity. We will ensure every components has its precisely defined place in a globally envisioned, modular, architecture. We will take care of not coding things before we need them, and ensure developers have a consistent, understandable, and documented platform.
  • We will take care to respect and use web standards where appropriate: XOOPS, like PHP, has to stay a glue between many more softwares, and standards are also done to facilitate interoperability, not just to confuse programmers.
  • We will take care of the way we collaborate together, communicating about things before they are implemented, ensuring additional people can join the core development as naturally as possible.
  • Then, if all this go well, we'll be able to take care of the way we can benefit from the flow of ideas and efforts visible on the forums and within other teams of the XOOPS project.

Adequate methodology should allow us to obtain a system able to satisfy as many of the various expectations actual XOOPS users have manifested during the last two years as possible:

  • Developers will have a consistent and expectable platform to build on, with libraries to help them build any type of Web-based application, not just “XOOPS modules”.
  • Professional users will have a flexible system that integrates itself well into their existing information architecture.
  • End-users will get an extremely powerful and customizable web building tool made of specialized and easy to understand independent programs, with metaphors interfaces they already know and understand for documents management tasks as well as in page/site building applications.


The operational / foundation layer


Exxos will be an object instantiation and runtime configuration framework designed to help building efficient, yet configurable and flexible PHP applications. It will allow every object to be switched between several “execution modes” to allow programmers to make flexible, configurable and adaptive versions of their components on one side, while providing an optimized and more scalable version at the same time.

Exxos itself will exploit this ability, and provide a powerful runtime configuration layer that should allow people to configure every aspect of their system. In development mode its factories will create and configure objects according to user preferences, to generate pre-configured extended classes that they will be able to instantiate directly in production mode.

This framework will also provide standard text encoding services made available locally (text encoding being the key to higher level internationalization functionalities) that will minimize the differences between existing back-ends like the iconv or mbstring extensions, as well as a standardized way to implement observers (or event handlers).

The XOOPS kernel

The kernel will be our own Exxos implementation, providing a global factory responsible of the instantiation of all the objects of this system, and taking care of the global boot and shutdown sequences. It will bring the following paradigms and features:

  • The notion of user identity allowing us to make user-aware applications.
  • The possibility to make localized applications, with the addition of a language service handling the management of strings collections and the translation of those strings (and that should normally support both gettext and a provided php class as its translation engine).
  • A path handler allowing developers and users to address objects or modules files and resources independently of their physical location (giving birth to the xoops:// virtual file system).
  • The notion of site, or host identity. Just like some web servers can be configured to support multiple sites or vhosts, the same XOOPS kernel will be able to operate several sites (differentiated using the request URI). This feature will be considered in the kernel factories, to make the preferences management system able to specify global but also site-specific settings.
  • The use of UTF-8 as this platform native encoding (although it will still be configurable to use any other internal encoding, for people who won’t need the benefits of Unicode).
  • The notion of application (or module). The kernel will instantiate the current module object at the end of its boot sequence, and verify that the current user is allowed to access the requested script.
  • The possibility to install additional “startup items“ that will be instantiated during every system startup, after the initialization of default services.
  • A globally available input filtering facility that developers will be able to use to clean up user-provided request variables before they use them. It will protect them from SQL injection or cross-site scripting and help them build applications that are safe from the earliest stages of their development.

The architectural services

The last part of this operational layer will consists of architectural services. This layer will contain various low-level frameworks providing standardized APIs to external services or systems. As most of the classes it contains will be used regularly and on every page request (a lot of them being tools that will be used by higher level components), they will be designed to stay simple and optimized, and to bring standardization and modularization more than features.


The XoopsDb framework will benefit from the standardization PDO will finally bring to PHP 5.1. The new version of our framework will be modeled after the PDO interfaces, ensuring this extension can be used directly if it's available (giving out of the box support for all the PDO supported platforms: Ms-SQL, MySQL, Firebird, Oracle, PostgreSQL and SQLite), but we'll also provide a fall back MySQL driver (and would also like to provide a MySQLi driver if people are available to do it).

This version of XoopsDb will also be encoding-aware, and automatically take care of text encoding conversion (using native driver support if available, or the Exxos provided engine otherwise).


The XoopsHttp frameworks will contain some of the Http specific components, like session handlers. An important point here is that we will ensure XOOPS 4 is build on the Http protocol, not against it. Throughout our whole development process, we will ensure XOOPS stays a Web building platform that uses the most obvious standards like this protocol as adequately as possible. Not only will this allow us to imagine XOOPS as just a part of a bigger platform or system, it will also be the reason behind some of our architectural choices, like the fact XOOPS4 will internally manipulate canonical, human-readable URIs, that will stay like this if possible, or get transformed to infamous xxx.php ones in the worst cases (as opposed to other programs that manipulate script locations later transformed using “shortURL functions”).


Smarty will be the first engine to be implemented in the XoopsTemplate framework (though differently than it was in XOOPS2 and with the addition of custom extensions to the default engine ), but depending on the way things go, we might add our custom template engine here, implemented with a compiler similar to the one Smarty has (but without some its almost never used features, to keep something simple and more scalable than what Smarty has become).

Core services

The core services layer will provide primary services built above the lower level architectural components, and acting as intermediary between application level MVC-oriented components.


The Authentication framework will provide two services: the authentication service (handling the whole authentication process) will be separated from the authentication driver (taking care of checking credentials validity), this last one becoming configurable. Several default drivers (LDAP, XoopsDb...) will be provided, but people will be able to design custom ones to extend this framework possibilities.


XoopsUi will bring the base tools later used to build advanced XOOPS4 applications user interfaces. One of the key elements for this will be User Interface Files that developers will be able to use to create/describe UIs (some kind of super-templates that can instantiate objects and provide several versions of an interface, made for different display technologies: HTML, but also XUL, or whatever). Based on XML, user interface files will be compiled in the same manner Smarty templates are, to ensure a fast access on production sites.


XoopsTheme will encapsulate the functions of the page building service, that wraps module output into a themed page. Page building will be enhanced will the addition of an intermediary application-level template, and the possibility will be given to objects to manipulate page-level meta data (so a widget inserted into a page can ensure its required style sheets and script files are fetched from the page header). More power will also be given to themes, as resources containers: people will now be able to use themes to customize any resource used to build the output (whether it is a template, style sheet, script file or image). When access to a themed resource will be requested, XoopsTheme will automatically check if a custom version exists in the theme, and modify the resource URI if it does. Access to these last features will be provided with the help of custom Smarty compiler functions, to ensure this doesn't become a scalability killer.

We are also considering the possibility of making some of this new framework features available in the 2.1/2.2 branch.


XoopsData will be designed to address some of the most important areas of functionality in document-based web applications: object graph management and persistence. The classes it will provide will leverage modules developers from having to take care of retrieving or saving objects properties from/to persistent stores, or from having to validate these properties values before they are saved to a persistent storage. Some of its key features will be:

  • A design using a completely model (as in MVC) oriented approach: XoopsData applications will not manipulate data stored in databases, and made accessible via Data Access Objects, but adopt an opposite approach and manipulate Documents and Content entities that will get saved to Persistent object stores.
  • It will transparently support distributed data stores (so the items an application get can come from different stores without it ever noticing this).
  • It will provide a XoopsDb storage driver, but also a file system based XML storage driver (to persist documents as XML files in the server file system), and allow the development of custom third-party drivers.
  • Its data stores will be language aware (so people can store multiple translations of the same document)
  • Each store will benefit from an own hierarchical organization system, allowing content to be accessed using the most understood path metaphor.
  • Data stores will be expandable using custom meta data sets, to support the additions of ratings or download counts to content entities.
This is a framework where a lot of features could go. However, as with everything else we will first ensure we have something working here and decide own many of the fancy features we will effectively want to implement in this version and which to keep for later depending on the people contributing.

Application Services

The Application Services layer will contain several frameworks based on the MVC pattern, to help build document (model) oriented applications as fast and easily as possible. The ApplicationKit will bring XoopsData-based Object controllers made to create, view or edit managed documents. The WidgetsKit will provide several default widgets that people can use to build powerful user interfaces (tool bars, enhanced form controls). While we don't think XOOPS should provide a full-blown controls library, at least we will have to provide a few default components as well as some standardization here, so 3rd-party developers can make their own custom XoopsUi widgets.

The Core Modules

The modules delivered with this new platform will fall into several categories:

  • System modules will provide several applications necessary to run and manage XOOPS sites, like the User logon module providing the system login window, or the new modular management console.
  • Content management modules will allow user to browse their documents collections: a content explorer will allow navigation through known data stores, and the default document viewer / editor will allow the edition of resources and documents that are not managed by a specific application.
  • The new XOOPS development tools will aim to give developers access to a completely integrated development environment: they will have applications to visually edit classes or new document types, and allow them to concentrate on real functionalities instead of spending half of their time on repetitive tasks. At this really early stage of development, we are imaginating these applications with an XUL user interface (this will depend on the possibilities offered by the XoopsUi classes, and of the volunteers we can get to work on this point).
  • Some of the functionalities offered by the developer tools will be reused to allow end-users to extend their sites functionalities without the need to code anything manually (like creating new model classes to add custom documents types), but whether we'll make these users use those applications directly or we will make some of their functionalities available somewhere else is to be defined.
  • Last, the old XOOPS2 core will be re-implemented as a XOOPS4 application. This will allow us to provide a maximum level of compatibility, as some of the classes XOOPS2 modules will use will effectively be the old 2.x ones (while most low-level classes will be bridged, to give old modules transparent access to some of the new X4 features).

OOO (Open source, Open design, Open development)

Our main objective during the development of this version, will be to make XOOPS a real open-source project, made highly collectively. From what I saw in recent forum posts, I guess most of the actual XOOPS users may not realize this importance of this change: this has never been the case in the past, the worst consequence of this being the inability of the XOOPS2 architecture to be easily enhanced in a way that could have allowed us to continue its development by a more collective effort.

This goal will bring a lot of changes to the traditional XOOPS development methodology. This means everybody can forget about the “code privately, release when finished” way adopted by previous core development teams, and say “Hello” to early alpha core releases, or to the longly awaited technical documentations. More precisely, these are the things you should be able to see during the next weeks:

  • Releases will be made regularly, in a more adopted “release soon, release early” way. We expect to make one new release approximately every two or three weeks.
  • A first alpha release will be made really soon. It will mark the start of this project as something collective. Programmers cannot work together if they haven’t got something to work on. We will have something right after this.
  • The sourceforge tools will be used during the first development stages. CVS of course, forums, whatever we find necessary. From the first weeks of June, existing mechanisms or expected enhancements will be described and explained on sourceforge, even if the number of people effectively working on the core is no more than one or two. The key to get successful contribution is to make people aware of how to contribute, and a lot of effort will be made about this, from the beginning.
  • After the Catalysis release, the core developers will start building a new Core development site, that would give us tools more tailored to our needs or more customizable than the Sourceforge ones. From this point, people needs will become what drive the additions made to the core.
  • Then, after developers, the new core will open itself to more and more people needs, progressively. Each person contributing to the XOOPS project, team after team, will be taken into account and will become part of the XOOPS noosphere: liaison, documentation, modules repositories, public relations. During that last part, XOOPS will evolve to become the tool these people need to collaborate and communicate. This will allow a complete rebuilding of all the websites, during the final stages of the Xoosphere project.
  • The XOOPS4 API will be entirely documented. Every class or component (maybe except really early and experimental ones) will have at least phpdoc comments attached to it. Interfaces freezing status will also be clearly indicated, so developers are aware of what may be subject to change.
  • A real “XOOPS core technical reference library” will be written in parallel to the core development (not an “API reference” but a real documentation, for humans: with texts, explanations, samples... Not a raw list of properties you can use to code, but something people will be able to read, so they can understand ).

Social Bookmarking Sites
Bookmark to Blinklist Bookmark to Delicious Bookmark to Digg Bookmark to Fark Bookmark to Furl Bookmark to Newsvine Bookmark to Reddit Bookmark to Simpy Bookmark to Spurl Bookmark to Yahoomyweb Bookmark to Facebook