Could we outline some "best practices" on how to achieve this ?

We can provide our application with methods to get a database, session, user etc. object and store those in our application.
But how would we replace the Factory::getApplication() call without passing the application object to every possible object (or even worse: to a static method) ?

This is where someone more knowledgeable than I comes in and talks about a dependency injection container. I legitimately have no idea how to work out the application object issue.

To some extend we need to reevaluate our entire architecture to do this. I guess this is a great playground to test this.

As long as we don't have a DIC I'd go with with Nikolai's suggestion to add these methods to the application. The router can than pass the application along to the controller.

We're already building the database object in the application (and passing it to Factory for those places calling it still) and I've extended Router to pass in the application. So, we're on the right track, the only place we're stuck is Factory::getApplication() for the moment.

Glad we are on the same page ;)

• Since we (hopefully) wont support a user/password authentication, and having GitHub as our only authentication provider, the user management can also be quite simple and a User object can be passed (or nulled) by another class for login/logout purpose. I don't think we need auth plugins at this point..
• Configuration file handling is also covered.
  BTW: PHP 5.4 adds a JSON_PRETTY_PRINT constant to the paramaters of json_encode() so we might build some simple config GUI :)
• I am currently trying out Rouven's suggestion using the session from the symfony httpFoundation and it works quite well - removing a lot of old code. Can we live with non database-based sessions (e.g. file) ?

So all that's left is
Factory::$application->foo[()]
to access all this stuff that our application provides now - almost like the Factory did before ;)

As much as possible, I don't think we need the plugin system at all (and if so, there's a small learning curve to the new Event package in the Framework).

Next hurdle is the User object. We're obviously without JUser for the moment, so suggestions are welcome for how we want to go about that.

The j.org space I acquired for the app is running PHP 5.3, so for the moment, that JSON_PRETTY_PRINT constant isn't immediately available (unless someone wants to emulate it). In terms of simplicity though, agree that any interface (user or config) should be just that.

I'm impartial to how the session is managed, just that we have a session system in place for whatever we may need it for.

So we merged into the Framework today DI and Services Providers code. Not in use just yet upstream, but it's available now.

We are not using Joomla\Factory anymore.