DI Container improvements

[rullzer]

The AppFramework has a DI system as well. However this system has some issues.

1. The DIContainer (https://github.com/nextcloud/server/blob/master/lib/private/AppFramework/DependencyInjection/DIContainer.php) is the basic container for each AppContainer. This means that for each app we load we initialize a new DIContainer. This quickly leads to an explosion of registerService calls etc. While 1 backend container would suffice. (My dev setup does over 2k registerService calls).

2. The ServerContainer does not extend the DIContainer. This means that we can't do fancy automatic DI there. And have to register everything manually.

A possible solution I see is the following:

There is 1 Container-Containter. This container only holds containers and the part of the namespace they are responsible for. The ServerContainer would register itself there just like any AppContainer would.

This would mean extending the query function. First check your own container. And if it is not there ask the Container-Container. The container container will then pic the right container to query.

This means that services will only have to be registered once in a container.

Comments/Input is welcome: CC: @BernhardPosselt @LukasReschke @icewind1991 @nickvergessen @MorrisJobke @ChristophWurst

[BernhardPosselt]

The system should work in a way that OCP\ prefixed things are resolved from the server container unless overwritten (re-registered) in an app container

[BernhardPosselt]

@rullzer maybe it would be a good idea if you could put some work into summarizing prior art, as in: take a look at existing containers in different languages and summarize how they work. Apart from that someone at ownCloud is working on integrating Symfony DI fyi.

[rullzer]

The system should work in a way that OCP\ prefixed things are resolved from the server container unless overwritten (re-registered) in an app container

Yes exactly that should happen

@rullzer maybe it would be a good idea if you could put some work into summarizing prior art, as in: take a look at existing containers in different languages and summarize how they work.

Yeah time time time ;)

Apart from that someone at ownCloud is working on integrating Symfony DI fyi.

Yeah I saw that. I don't have a real preference.

[rullzer]

Actually I think it might make more sense to do this right with separation of concerns. Then we can in a later stage always switch to symfony DI if we think that is worth it. For now I don't see a big advantage yet.

[BernhardPosselt]

Right, things work well right now and apart from moving stable and very infrequently touched code outside of our maintenance scope I don't think symfony DI doesnt really add anything of value. We should however keep it in mind when refactoring this so it is easy to switch to it.

[rullzer]

Yes and I think if we pull the current stuff apart using any framework becomes already easier.

But because we have the resolving part etc already in place I don't either see a hugely added benefit of switching to symfony.

[rullzer]

Ok after thinking about it and discussing more I think the following approach will be cleaner

1. Move over interface registrations to the ServerContainer as alias.
2. Extend the query method of the DI Container

• First check own container
• Then check ServerContainer

This just moves things around and does not change any behavior.

• If an app overwrites a service it is just for that app
• If the app Foo wants to load a class OCA\Bar
  • First looks in its own container (not found)
  • Then we query the ServerContainer https://github.com/nextcloud/server/blob/master/lib/private/ServerContainer.php#L73-L90
  • The serverContainer will redirect the query to the correct app container

[rullzer]

Basically done