Cleanup I*Config classes

[PVince81]

So far we seem to have lots of classes and interfaces just to read the config, some legacy and some new.

We need to clean up this mess.

Here are a few:

• IConfig
• OC\Preferences
• IAppConfig
• OC_Config
• OC_AppConfig

@icewind1991 which ones do we want to keep and which ones should go ?

[BernhardPosselt]

You need to split the configs based on their dependencies:

• You can always read the config/config.php
• In order to read app and user values you need to first read the config/config.php

->

• Keep IConfig as is and let it read all values but inject the class that is required to read and write the config/config.php into it so you can also set system values. getSystemValue and setSystemValue on the IConfig class just call through to the one that reads the config/config.php
• Get rid of all the other stuff that makes sense

@MorrisJobke

[MorrisJobke]

see also stuff like #13736 and #13104

[MorrisJobke]

Drop of OC_Preferences: #13869

[MorrisJobke]

Drop of \OC\Preferences #13870

[DeepDiver1975]

While reviewing #13938 I really wonder if IAppConfig shall die ❓

It's an isolated and easy to use object.

[BernhardPosselt]

Stuff that is only available in IAppConfig:

• Delete all entries for an app
• Delete a key

The rest is code duplication. We might want to add those methods to the IConfig interface and then kill it, that is if those methods are actually used in our code

[MorrisJobke]

@Raydiation see #13938 ;)

[MorrisJobke]

@DeepDiver1975 We can also handle it all in IAppConfig, but we shouldn't provide two ways of doing this. Either in IConfig OR in IAppConfig.

[MorrisJobke]

The "or" is an exclusive one ;) Read it as an XOR ;)

[BernhardPosselt]

IMHO makes no sense to put the setting of app config values in one class and the deletion of values in another class :)

[MorrisJobke]

IMHO makes no sense to put the setting of app config values in one class and the deletion of values in another class :)

I moved all missing methods over to IConfig and deprecated IAppConfig with #13938 ;) The question here is if we want to do it in this way, or if we want the AppConfig be a separate interface, but then I would remove the methods from IConfig.

[BernhardPosselt]

Separate interface makes only sense if we have the exact same signatures. That way we could keep backwards compatibility and let iconfig inherit from iappconfig.

[MorrisJobke]

Latest cleanups went into 9.0 -> closing

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.