Plugins: add storage format and clarify capabilities in status

[Namoshek]

Situation

Currently storage plugins are either named by their format (e.g. ini plugin) or have the format as part of their info/provides list. Because this list is not consistently structured, it is impossible to know which provides key represents the actual format supported by the plugin.

Furthermore, some plugins cause troubles when being fed with arbitrarily structured data because they can only operate on a well-defined structure (e.g. fstab, hosts).

This is the implementation task following the discussion in #994.

Requirements

It should be possible

• to find plugins based on formats (already possible).
• to enumerate all plugins with their respective format.
• to know whether a plugin is limited in certain terms (e.g. cannot represent arbitrary data, can only read or only write).

Implementation

• storage providers that do not support an actual format will be renamed to storage/info.
• storage providers that support a format will get the format as value for storage, e.g. storage/ini (separator to be discussed in Separators #1010).
  • with help of CMake also storage and ini will then be added to the provides list to keep backwards-compatibility.
• additionally to the format, storage plugins will get
  • the status limited if they cannot consume arbitrarily formatted data (e.g. hosts plugin).
  • the status readonly if they can only read files.
  • the status writeonly if they can only write files.

[markus2330]

Very clearly written, please also add this text to the documentation of infos/status and infos/provides (in doc/CONTRACT.ini).

One point is missing: in the PluginDatabase (src/libs/tools/src/plugindatabase.cpp) you need to do the split-up using the seperator, too. (in the same way as done in CMake).

EDIT: Or was your plan to also modify the generated readme.c? That would work, too.

[Namoshek]

If I already need to modify the CMake function, it might be easier doing both there.

Did you btw. already decide whether we should use a list or an array for the provides list? (An array would probably require quite some changes in plugindatabase.cpp too?)

[markus2330]

If I already need to modify the CMake function, it might be easier doing both there.

I am not sure about that ;)

Did you btw. already decide whether we should use a list or an array for the provides list? (An array would probably require quite some changes in plugindatabase.cpp too?)

provides? It is not a list, nor an array, it is a space-separated entry in the contract. Do you mean examples? Please create separate issues for separate questions.

[Namoshek]

I am not sure about that ;)

Well, wait... why is it necessary at all to modify both, the CMake function and plugindatabase.cpp? I think it is enough to split at one of both points and the preferred one seems CMake as it is the earliest possible?

provides? It is not a list, nor an array, it is a space-separated entry in the contract. Do you mean examples? Please create separate issues for separate questions.

Maybe I mixed up something, forget about it. 👍

[markus2330]

Well, wait... why is it necessary at all to modify both, the CMake function and plugindatabase.cpp? I think it is enough to split at one of both points and the preferred one seems CMake as it is the earliest possible?

Yes, I am afraid it needs to be done twice:

1. In cmake/Modules/LibAddPlugin.cmake the infos/provides determines which plugins of PLUGINS are added/excluded. See regex line 150
2. The mount tool reads provides via src/backendbuilder.cpp, and thus always tries to use plugins that provide something (via pluginDatabase->lookupProvides)

[Namoshek]

Oh ok, wasn't aware 1. was even possible. But if I do a split in 1., then maybe I can reuse it and add the partial keys in cmake/Modules/LibAddMacros.cmake right away?

[markus2330]

Yes, you could do so. Then it will also work with e.g. shell code that does kdb info <plugin> provides, so it is even more generic.

[Namoshek]

Task done.