elton
18b40bb6ce
Andreas: "koennen wir da nicht noch einbauen das der nur feuert wenn tatsaechlich was anliegt? das wuerde ich nicht dem client ueberlassen sondern schon im notifier loesen. der mail notifier muss doch auch sowas machen." Richtig -- und der Vergleich trifft den Kern: goimapnotify hat das Problem nicht, weil IMAP IDLE ein echtes Ereignis liefert. Bei Mattermost fehlt der Push fuer Kanaele, und mein Boden hat das mit blindem Feuern ausgeglichen. Jetzt sieht der Boden selbst nach: je Kanal ein posts?since=<marke>, das bei Stille leer zurueckkommt. Eigene Beitraege und system-Ereignisse zaehlen nicht, sonst loeste die eigene Antwort den naechsten Durchgang aus. Ein Dutzend Kanaele bei 60 s Takt sind zwoelf Anfragen pro Minute -- gegen einen Modelllauf ist das nichts. Der Weg dahin war laenger als noetig, weil drei Mattermost-Felder auf dieser Instanz luegen: last_post_at blieb nach einem neuen Beitrag unveraendert, msg_count zaehlte weiter obwohl der Kanal als gesehen galt, und last_viewed_at war neuer als die ungelesenen Beitraege. posts?since= ist das einzige, das nachweislich stimmt. Gemessen: zwei Durchgaenge Stille ohne einen einzigen Aufruf des Befehls, dann ein fremder Beitrag -> gefeuert. Genau das Verhalten von goimapnotify.
9 lines
234 B
JSON
9 lines
234 B
JSON
{
|
|
"url": "https://team.42i.org",
|
|
"token": "hpk77zktmpd7xcxwn4fs1yssnh",
|
|
"on_mention": "echo ' >>> GEFEUERT (Grund: '$MM_TRIGGER', Kanal: '$MM_CHANNEL')'",
|
|
"floor_seconds": 10,
|
|
"debounce_seconds": 1,
|
|
"away_after_seconds": 120
|
|
}
|