Idea: Expand Modules into a full Plugin/Extension system

[tbirrell]

Would you ever consider expanding the modules into something like oneso/laravel-plugins to allow people to write plugins that would not be intimately tied into the code base?

It would be very helpful for those of us who fork and host our own versions. It should not be hard to tie into the existing Eloquent Events and add some event listeners to other locations in the code. That way if I make a change to my version that you don't want in monicahq/monica, I can add it to mine as a separate entity without having to deal with updates from monicahq/monica potentially overwriting it.

On the web app, it would enable more customization, as well as allow for the behind-the-scenes code to be opt-in, rather than the current opt-out format. This should allow for some optimizations to take place that currently can't since a request would only load the user's presets, rather than have to ask about everything (something that, admittedly, is probably not an issue now, but could be later.) You could also use it as a way to test ideas quickly, by writing a plugin, and then if people like it, bake it into the code. Similar to how Gmail Labs (or any other beta test system) works.

This is definitely something that would help the devs more, but it has benefits for both sides. It's also something that might be a massive change to the code structure. Maybe a good candidate for a 3.0 release? IDK, I mostly wanted to get your take on it and start a discussion if it was something that captures your interest.

[tbirrell]

Additionally (in light of the Q1 objectives), incorporating this system would be in line with the goals in the README. Specifically "we value simplicity over anything else" and "we want to keep the codebase as simple as possible". It feels like the amount of features is getting overwhelming, so I'm glad that this is slowing down for the quarter. Of course, I know I can just stop updating my instance, but I want to be able to keep contributing. A system like this would allow for continual new features without getting overwhelming or making the codebase a monolithic behemoth.

[asbiin]

@tbirrell that's really interesting! On oneso/laravel-plugins I read:

Plugins must be in app/Plugins.

How a plugin will be installed in this directory?
How to manage docker instances?
How to manage versions/update of plugins?

[djaiss]

Yep I've already considered having plugins.
This is an excellent idea but I don't know what to put them in place in practice. @asbiin raised a good question with the management of the versions but this is not the trickiest part in my opinion. I think we need to think about security and how to make sure we don't have nasty side effects like allowing a plugin to read something they shouldn't be able to read - that's the part that scare me the most.

[tbirrell]

That's a good point. I hadn't thought that far ahead. I was focusing more on the technical feasibility of it, but security is a good point. Its been a while since I've used WordPress, but I might go back and take a look to see how they handle that.

In the meantime though, adding it to the structure of the app would allow the devs who fork to test it out, and you'd be able to verify any code you add by hand for cheap feature testing on .com. The more I think about this, the more I realize the enormity of the task I so blithely suggested. You've obviously given it thought, so if you are serious about plugins, and you wanted to share some of that and mark a starting place (even if this wasn't a focus for you two), I'd be happy to contribute.