Meta: Plugin system

[Leptopoda]

Clients not strictly in the drawer should be moved into a new type similar to AppImplementations called Plugin. A plugin differs from a client as they don't require to be tied to an app and are usually more entangled into the neon framework itself. Clients would have their Bloc interfaces inside the framework. An app dev would be able to both specify a list of Clients and plugins improving the ability to configure them and also more tightly handle native dependencies or permissions.

Potential new plugins:

• [ ] User provisioning
• [ ] Unified search (with configuration options to disable global search)
• [ ] Add a sync plugin
• [ ] push_notifications (with the native dependencies)
• [ ] #303

Todo:

• [ ] Hide the bloc of the clients from other apps (making them protected)
• [ ] Potentially interfaces to be called by other clients themselves (files plugin that can be used without bundling the entire files app
• [ ] login plugins supporting custom authentication methods like pre provisioning or the ability to leave QR login out to avoid relying on the camera permission
• [ ] Rename AppImplementation to Client to avoid confusion

[provokateurin]

I think we need to put in some more thought on how different clients/plugins can know about and interact with each other. Maybe we can starting by drafting something in PlantUML again which we can later add to the docs as well? Just to have a nice overview of the architecture and a plan for the implementation.

[provokateurin]

In my head every server app will be implemented by either a client or a plugin. For the core we will split it even more to separate features like unified search, login methods etc. I think it is quite important to have good guidelines on how each feature should be implemented and where we draw the lines between clients and plugins.

[provokateurin]

I think we should introduce some more abstractions for the plugins so we can try to keep most stuff generic in a way and don't customize everything in the framework. For example there can be a class called FilesActionsPlugin and all the plugins that extend this class can modify the files browser in a way, like adding a sharing menu for example. The same thing should work for other plugins that are in the app bar (like unified search or notifications).

This needs some more thoughts though and a proper UML diagram should make this much clearer.

[Leptopoda]

For now we do not see any benefit of such a major refactor. Once we have a need for it we'll revisit the idea.

[Leptopoda]

@provokateurin should we close this as we already discussed our general direction with a repository layer?

[provokateurin]

I think we should still keep it open, this is not only about those issues as we also need the new app registration stuff and so on.