Join GitHub today
Plugins/Protocols manifest.json overhaul #1181
What does this PR do?
Re-architecture the way plugins
List of currently supported manifest files properties:
(internal backlog task: KZL-430)
@@ Coverage Diff @@ ## 1-dev #1181 +/- ## ========================================= + Coverage 93.8% 93.92% +0.12% ========================================= Files 91 94 +3 Lines 6484 6538 +54 ========================================= + Hits 6082 6141 +59 + Misses 402 397 -5
referenced this pull request
Aug 10, 2018
That looks like quite a lot of code to me for quite a simple feature.
Moreover, I am a little concerned that plugins and protocols share some features, as they are fundamentally different.
As an example, this is probably already the case, but imo, protocols init should not throw a PluginImplementationError in case of failure.
About the quantity of code: this is mainly due because we already handled manifest files, but:
Also, I found out that manifest values weren't properly tested. All in all, I agree: a lot of code for a simple feature, but that's mainly existing code that was moved around or rearranged, and a lot of new errors are added to make plugin development easier to understand :-)
@benoitvidis > I implemented all your requested changes, except for the "privileged mode as a default for protocols" remark. After thinking about it, I think we are (somewhat) agreeing that this mode has no sense in itself for protocols, since they have access to the kuzzle object anyway. So the following question remains: should I expose a kuzzle object on purpose or not (I think we shouldn't, and that this "mode" has to go)
After sleeping on it, it occured to me that the privileged mode can only be activated by plugins anyway, the property does nothing to protocols. So I moved that part to the plugin-specific manifest class, the property is now completely ignored by protocols.