Webhooks #2323
Replies: 1 comment 1 reply
-
Hello, i perfectly agree with you on the fact that the integration interface (we're talking about this) has to be simplified, but at the same time you have to understand that in any project, any additional feature means additional maintenance work, especially if such feature is just a simplification of an existing one, that will still exist, causing confusion in users about which one to use. Webhooks can already be used without issues by placing runOnStop hooks are planned, are tracked in #1464 and will be surely developed in the future (and a PR would be welcome). I'd rather avoid merging specific integrations (i.e. events sent to Redis, Kafka, MQTT, AMQP) since they would open the way for any kind of integration, tripling the dependencies, while the same exact thing can be done by placing a command line in |
Beta Was this translation helpful? Give feedback.
-
A solid need for this feature exists. I am sorry but a SIGINT wait in a script is kludgy and definitely not ideal. I was about to make the changes necessary to see a webhook in the context of a source connecting and disconnecting (publish/unpublish), until I saw the PR (#2207) and someone had already done it. Sadly I saw it was not merged and closed. There is no public discussion on why that decision was bad for this project other than you told the author the reasons why, but not publicly. I am just trying to understand your perspective. aler9 Can you take a minute to explain why this PR was denied? I am not advocating for anyone, it's just that there seemed to be a decent solution for webhook call outs for when a stream source connects and disconnects from publishing. There seems no better solution other than this ticket for an enhancement. I certainly don't want to put the work in to contribute to just get it shot down for lack of knowledge of the reasons why this other PR was not merged.
Thanks for your time
Beta Was this translation helpful? Give feedback.
All reactions