I wasn’t meaning to add hooks every where so the code becomes a nightmare to understand, but indeed taking advantage of pipelines. One still needs to define where the plugins can inject their functions (in the pipeline, before rendering, after rendering, …), I don’t see a way around that, and every new hook like this makes the whole more difficult to understand when a bug appears.
I’m with you on this. It’s a trade-off but making them orthogonal would prevent a lot of headaches and nasty bugs. There is always be someone who wants to alter the functionality of another plugin in a way that wasn’t designed, but you could scratch that.
One DB per plugin is just the easiest/quickest way to make it work while ensuring total isolation and programming ease, but any other ways like you described would be acceptable. Your app will have to handle all that new user in DB + setup all rights + creating the table and vice versa when the user pauses or uninstalls the plugin. My idea is only to be able to ensure that plugins cannot alter in any way data that do not belong to them, and let the plugin writers in charge of their own little migrations orthogonally. Non technical users shouldn’t have to care about the how.
I’m used to this kind of thing and it’s not so bad, but indeed as other said it seems to be easy to just keep it all in elixir. Keep in mind that allowing several languages with a (strict) API allows people from various backgrounds to write or import plugins, which could be a plus. It’s also a minus as the bar of entry will be lower, so…
