Technical insights and software architecture

Deep dives into PHP development, Horde Framework evolution and practical software engineering. Focused on real-world solutions for complex technical challenges. “Always close to the source”.

Core Topics

PHP, Horde Framework, authentication systems, composer workflows and modern development practices.

Long-form Analysis

Comprehensive technical articles exploring architectural decisions, migration strategies and lessons learned from real projects.

Code & Community

Open source contributions, framework development and sharing knowledge with the PHP developer community.

Dark is the road you wander

While we are pushing forward day by day, processing user reports of alpha and beta version bugs and quirks, we sometimes wonder what path lies ahead beyond those minor worries. Where do we go? I want to know.

We have 150+ libraries and apps which are more or less in focus and a body of ancillary tools, dead experiments and outmoded integrations we eventually must let go. Despite all our efforts we still haven’t migrated off everything which we already replaced – in concept or in other places – and there’s so much to do which doesn’t fit into those last few weeks left before the stable release. With so many light years to go and bugs to be found, what’s the plan after all?

So let me recap, rephase, sharpen if you want…

Freedom vs lib(erty)

There’s been this very sharp boundary between the src/ world in which we enjoyed a lot of freedom to experiment, test-bed, err, try and try again for concepts which work and those which looked nice at first. There was only one rule: Do what you want but be strict about it. Signatures, Contracts, Strict Mode, PSR-4 and PER-1 – but I guess it’s over. We are nearing a stable release and cannot make & break stuff anymore. We must follow the rules now.

In lib land, it was the opposite. The interfaces were loose and ancient contracts from another time. We may not break them but we can interpret them a lot. Normally a new major version is the time when you throw out auld stuff but with this long phase of no official stable version we did not dare to break things a lot.

On Borrowed Time

How does that work. So Horde 6 is nearing what we call stable on a promise – What is in libraries in src/ now will keep working for a while until Horde 7 comes along and potentially much longer. This is where we do the features, the new code. In lib/ we keep as much compatibility into the past as we can, as long as we can. If a next version of the language breaks it, it’s broken. We are actively migrating off this branch. Often it’s just stricter rules but in some cases it’s a completely different approach. Horde_Http_Client is a very unique and ancient way of doing HTTP requests. Horde\Http\ClientInterface is a standards implementing different animal which you can combine with a lot of stuff not built here. Horde_Core is infested with globals, side effects and implied state. Horde\Core\ about explicit interfaces and loose coupling. Some conversions are copy-paste, some are radical steps forward. Everything you see in lib/ will likely be gone by Horde 7.

Applications Welcome

The age of holistic frameworks is over. Everything is much more pluggable, more interchangeable and you can combine and mix and match freely. We embrace this openness. We don’t want to reinvent every interface and make it our own, we are opening the playground for everybody. Build your apps with our tools, we will use your libraries and tools where we see fit. It’s time to make many components stand on their own and not have hard dependencies on a kitchen sink of other parts you have not invited or requested.

The bottom line

lib => src
PSR-0 => PSR-4
eternal loose interfaces => strict types and change
kitchen sink => loose coupling, mix & match, interoperability
implied state & globals => explicit interfaces
long years of no official release => release fast & often


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *