Future of custom actions

[sagikazarmark]

Now that plugins are added to sftpgo, what's the future of custom actions? Are they going to be deprecated eventually?

[drakkan]

Hi,

Although plugins and hooks may overlap in some cases, they cater to a different user base/use case. For example for system admins is quite easy to write a bash script and use it as hook.

Plugins allow me to provide ready-to-use functionality for uncommon use cases without adding the implementation within SFTPGo. For example some users in the past have asked for integration with pub/sub systems, adding them directly in SFTPGo would significantly increase the size of the binary, a plugin offers a ready-to-use solution without adding a feature that many users do not use directly in SFTPGo. Notification hooks are still useful for more specialized use cases and for people that want to integrate SFTPGo in their system without writing Go code. Although plugins can be written in any programming language it is unlikely that anyone will write a plugin in PHP and so some users would prefer the hook system.

So I want to support both plugins and hooks and let users choose what best fits their use cases. For now I am thinking of plugins as a way that allows me to extend SFTPGo, let's see in the future if others will contribute other plugins or improve existing ones

[drakkan]

From a maintenance (and contribution) perspective having two different solutions for very similar problems might be a burden.

I was thinking maybe hooks could be reimplemented as plugins?

Anyway, I was mostly interested in long-term plans for hooks. Thanks!

Yes it might be a burden but we have to maintain hooks. Proprietary software similar to SFTPGo have hooks, at least in their enterprise versions, and so users expect this feature. Some proprietary softwares also integrate things like goja to allow users to extend the software in javascript, honestly I want to avoid things like this and hope hooks and plugins are enough for all use cases

[sagikazarmark]

I'm not saying drop hooks, I was just entertaining the idea to reimplement them as plugins.

[drakkan]

I'm not saying drop hooks, I was just entertaining the idea to reimplement them as plugins.

I don't want to force users to write plugins, the current hook system allows SFTPGo users to integrate custom workflows using a simple bash script or sending plain http get/post to their existing systems. I think this is an important integration feature and I don't want to drop it.

Currently there are features that are not supported using hooks (for example the metadata plugin) and other features that are not supported using plugins (for example pre-actions), we could expand both hooks and plugins in the future if there are valid use cases.

Thank you for your work on the helm chart, much appreciated!

[sagikazarmark]

I don't want to force users to write plugins

I mean keep the current hook config, but the implementation could utilize the plugin system. Basically you would implement the plugins that users can configure through hooks.

Don't know if it's feasible though, just an idea to keep the implementation simpler.

[drakkan]

I don't want to force users to write plugins

I mean keep the current hook config, but the implementation could utilize the plugin system. Basically you would implement the plugins that users can configure through hooks.

Don't know if it's feasible though, just an idea to keep the implementation simpler.

Uhmm ... that means we should forward all events that are currently exposed as hooks to a plugin. This plugin will start a system command or make an http request based on the SFTPGo configuration.
This will add a little overhead, I think almost all SFTPGo users use at least one hook (for example to receive notifications for uploads etc ...) so this plugin should be installed by default.

I will consider this option, the SFTPGo code would be easier to maintain, but my first impression is that I don't like it very much.
Maybe thinking about it more I could change my mind as it has happened so many times in the past

[kossithedon]

Now that EventManager is available since v2.4.0, in which case one should be used instead of another ?

By reading the documentation, EventManager and custom actions allows to do nearly the same things. In which case, do you recommend to use custom actions instead of EventManager ?

Have you planned to depreciate custom actions in advantage of EventManager or it is still safe to use it ?