The Big One
All the roads lead to this
If you have been following the updates on the openpsa/midcom development posted here, you will have noticed that between all the refactoring, an important goal of development has always been to make the software more accessible to the rest of the PHP world. In fact, more often than not, this is what triggered many of the larger restructurings in the first place.
The first step on this road has been adding support for Midgard 2, which enabled us to run on PHP 5.4 and beyond as well as on different database types. PHP 5.4 support also meant significant changes to openpsa's dependencies, many of which had still been from the PEAR era (and a few of them still are). The move to Composer/Packagist-based distribution has been quite helpful in that regard, since it provided access to a plentiful source of current libraries. It also provided the basis for the new installation system, and has made openpsa more readily available to others who might want to integrate it into their projects.
So all in all, openpsa has been slowly moving into the bigger PHP world. But while these were all helpful and necessary steps towards better portability, one rather severe constraint remained untouched: The need to install a custom PHP extension and its associated libraries.
This may not be much of a problem for development, but restricts the choice of hosting options considerably. Basically, all non-Linux and most off-the-shelf managed hosting solutions are out of the question, and running multiple Midgard instances on the same server has always been somewhat problematic, so that only leaves you with running self-administrated individual VMs. And any project that wants to use parts of openpsa will limit itself to the same reach, which is not really much of a selling proposition.
The problem of course is that Midgard is not merely some dependency that could be switched, but rather the foundation on which the entire midcom framework and in turn openpsa are built. So for this not to turn into a multi-year, ground-up refactoring effort, any potential replacement would have to provide the exactly same behavior and API, essentially a Midgard without Midgard.
It took a while to figure it out, but it looks as though this Zen-like construct might actually be achievable, especially since the framework is in a transitory state as well: As mentioned above, currently both Midgard 1 and 2 are supported, so at the moment, we're restricted to the rather basic set of ORM features available in both incarnations. Which means that the requirements an alternative ORM must meet will never be lower than they are right now.
The most obvious candidate for such an ORM is Doctrine of course, but the fact that Doctrine uses very different paradigms than Midgard has long made this seem like an impossibility. Until recently, that is, when inspiration struck, and work on an adapter finally started showing some very promising results. It turns out that the baseline API required is still quite a handful, but some important checkboxes have already been ticked, so at this point, it looks as though a reasonably complete adapter could be written in a reasonable timeframe.
What's more, read access to Midgard databases already works quite well, so once the adapter can run in parallel to the Midgard extension, it could already be gradually introduced into existing applications to provide more expressive select APIs for performance-sensitive areas, without breaking Midgard 1 support.
Where this all leads remains to be seen, but the next important milestone will be to get openpsa's test suite to run, which might still take quite some time as there is a lot of ground to cover. Then, running actual application instances will be another big task. Assuming we actually reach the point where the Doctrine adapter (currently called midgard-portable) can act as a drop-in replacement for Midgard 1, an interesting choice will present itself: To either use Midgard 2's API or Doctrine's to further advance the project. Today, there is no way to tell which way that decision might go, but the point is: We will have a choice, and the means to provide better interoperability either way.