MidCOM 2.4 finally released, and a outlook into the future
2005-06-09 19:02

It took some while, but as a German saying goes, good things take their time. But finally, I have managed to solve all the issues that prevented the release as I originally planned it. The performance bottlenecks are under control and I'm ready to move on for the new features for 2.6.

While MidCOM 2.4 introduces a good deal of new features, it has a couple of hidden goodies only visible to developers.

Since I started with the Filesystem Transition, I had been refactoring the original, over three years old MidCOM code to match my new standards. Many parts of the old core cannot stand up to the requirements nowadays components. This is why I am in the process of refactoring large parts of the framework.

To start with, I'm introducing base classes to ease component development. Already stabilized and avaialble in 2.4.0 are the component base classes. As I have written before, they simplify component building greatly and allow me to enhance the component API easier then ever before.

2.6 now focusses on three things: Authentication/Authorization, MgdSchema and Multilang integration. Especially the first one requires the ability to hook into many places in the framework, thus requiring a more unified handling of the IO being done. On the long run, probably for the next major release after 2.6 this will give the ability too do automatic checks for object availability there (this needs time until all components use the new framework).

The important part here is to provide new classes for the database IO on one hand, but to retain a certain degree of backwards compatibility to the old API, so that we do not have to rewrite every component from scratch. A first glimps of the new classes can be found in the MidCOM API documentation I have on Nathan, in the midcom.baseclasses section.

Also in that documentation you can find a few new classes prefixed midcom_core, which is the beginning of the authentication framework outlined in MRFC 15. It is far enough already so that it can load and merge the complete set of privileges assigned to a user directly and indirectly through the groups the user is a member in.

The next step, which I will start tomorrow is to implement a) a similar merging chain which is capable to collect permissions from content objects and their parents and b) put all this together into the main auth service class.