IMO, the sink shouldn't bother which events to publish. Instead, we can have event change capture & output rate-limiting as separate pipeline elements which can be used with notification sinks. So it gives users the flexibility to limit events or not, depending on their use-case. What do you think?
pipeline: [event-source -> output rate-limiter -> notification-sink] Grainier. On Tue, 26 May 2020 at 21:47, Philipp Zehnder <[email protected]> wrote: > Hi Grainier, > > this sink is very cool and useful. I directly merged it. > > @all I think we still have a little conceptual problem with our > notification sinks (e.g. Notification, Email, …) > Currently we emit a notification for each event, even if the event did not > change. This could annoy users and also be counter productive as you don't > want to receive hundreds of messages. > We need a solution to set the maximum number of notification or just > notify the user when the situation changed. > Any ideas on that? > > Philipp > > > On 26. May 2020, at 16:28, Patrick Wiener <[email protected]> wrote: > > > > Hi Grainier, > > > > this is really nice. We were at some point actually talking about such a > sink so super cool > > that you implemented it. I used telegram once in another project where > one was informed > > about alerts/warnings and quite liked it. > > > > Thanks for the contribution and valuable work. > > > > Patrick > > > > > >> Am 26.05.2020 um 15:25 schrieb Grainier Perera <[email protected]>: > >> > >> Hi all, > >> > >> I've implemented a publisher to send notifications to a Telegram > channel. > >> Since Telegram[1] is a free and cross-platform application, I think this > >> will be a good addition to notification sinks. What do you think? > >> > >> Issue: https://issues.apache.org/jira/browse/STREAMPIPES-144 > >> PR: https://github.com/apache/incubator-streampipes-extensions/pull/16 > >> > >> [1] https://telegram.org/ > >> > >> Thanks, > >> Grainier. > > > > >
