Plugin questions

[gerneio]

Out of curiosity, why is the plugin feature a separately maintained branch? Is it still considered to be in beta testing? Or just didn't want the bloat in the main repo? Didn't really seem like there was that much of a diff between the two, and I do see that you occasionally align the plugin branch with the main branch. Or perhaps you didn't want it accessible unless someone specifically opt'd in by using that script instead? Seems like something that could easily be solved with an off-by-default feature flag.

Personally, I've been melding with the plugin branch, with the purpose of having a .NET project start & configure the emailproxy (via Python.NET) while also being able to have my actual plugin logic for the receive_from_client and receive_from_server methods within .NET itself as C# classes. Basically have a lightweight python plugin class that bootstraps a managed C# object factory passed into the python runtime/scope on startup. Got a working prototype, which is pretty dope (as a .NET user at least).

Anyhow, I noticed that the plugin branch isn't 100% up-to-date, but I do realize that you only recently pushed some of those changes. Was just mostly curious as to why you're keeping them separate.

Great work on the plugin feature & samples!

[simonrob]

Thanks – it's a good question. I did consider merging it into the main version of the proxy a while ago, but a few things made me decide not to:

• Originally this was an experimental feature, so it was in a separate branch. That being said, for at least a year it's been considered stable (and I myself use it in many different ways on a daily basis).
• Partly because of my own early implementation choices in the proxy, and partly because this sort of thing is just quite difficult to do well, it would be hard to integrate this feature with the pre-built releases (e.g., the Windows/macOS binaries; the PiPI package).
• It's potentially less secure – someone installing a version that supports this feature could potentially expose themselves to malicious plugins (e.g., when following a carefully crafted third-party guide), whereas this is not possible with the main builds of the proxy. The way things are, only someone who has at least enough know-how to set up Python can use this branch.
• It's a pretty advanced feature, and the documentation is sparser than the rest of the proxy. You need to understand the underlying IMAP/POP/SMTP protocols in order to be able to develop plugins, and it's fairly easy to get things wrong. I suspect it would lead to far more support requests, and I don't have capacity to take that on.

That said, it sounds like you've had a nice idea about how to use this feature. I'd be more than happy to take pull requests for improvements or additional examples here – I personally find it to be a really powerful way to manage email, and I'm glad that others do too.

Edit: I've also just updated the documentation to explain the newer example plugins/helpers that weren't covered there. Thanks for the prompt!

[gerneio]

Understood. I guess my main concern here was with the plugin branch being behind the main branch w/o manual intervention. Not sure if there's an automatic way of keeping them in sync, at least with how they are configured.

Some thoughts on how to solve this, I'm betting there's a way we can make it to where 1) the feature is enabled via a config setting (off by default) under main branch, 2) the user must specifically download a plugin_loader.py script (from modified plugin branch?) that will bootstrap the plugin experience, and 3) the user would still need to create the plugin folder and copy in whichever plugin scripts they choose to use. That way the plugin branch doesn't necessarily need to be a copied and modified version of the main branch, but is also separate enough that a user can't accidently enable it and make their setup vulnerable, especially since it requires 3 different manual steps to enable (as proposed above). This probably doesn't play too well with pre-built releases and such, so I'm sure there's more to consider there...

Anyway, just food for thought right now. I'm heading out on vaca tomorrow till after the beginning of the year, so won't be able to contribute anything specifically here.

[simonrob]

To be honest, the main reason I don't always update the plugins branch on every commit is that I have no real idea whether anyone other than me uses it regularly. I always pull in any major or bug-fixing changes, and it is updated to track every official release of the proxy. In addition, the script as a whole has now reached a state where there is little else to change except for bugfixes or perhaps further GUI and authorisation flow improvements. So I think this is in reality a relatively minor concern.

Thanks for the suggestions about how to integrate this feature. I've thought about this sort of approach before, but rejected it due to the additional complexity it brings. And as you point out, the pre-built releases are a difficult situation to resolve in a satisfactory way. If you're happy just tracking the plugins branch, you're really not missing anything major.

Because of this, I'll close this issue for now because I think the current situation is acceptable, but feel free to re-open if you have any other ideas about further improvements. And please do share any interesting plugin ideas you come up with. Enjoy your holiday!