pb-notify: Notify for all mirrored notifications and pushes #2
Assignees
Labels
Comments
|
Remark: if I implement this feature, then because of znc-push, this gives me a universal way to receive IRC notifications on all my devices. |
tsani
added a commit
that referenced
this issue
Apr 30, 2017
pb-notify now dispatches notifications when pushes are received. See #2 although we still don't implement full notification mirroring. This is done by watching the event stream for push-type tickles. When one is received, the list of pushes since the last batch has been processed is requested. Each is formatted appropriately is dispatched as a libnotify notification. Architecturally, this is done with a separate thread with an IORef holding the timestamp of the last processed push. Initially, this variable is filled with the timestamp of the latest push with activity in the account. This thread is synchronized with the event-loop thread via a channel. When a tickle is received on the event-loop thread, it sends a message over the chan notifying the HTTP thread that the list of pushes needs to be updated. The connectivity problems -- see #1 -- are partially resolved. Connection to the websocket is wrapped with exception-handling code so that it can be retried every five seconds. HTTP requests are also wrapped with retry logic until they succeed. Waiting for messages on the event stream is wrapped with a timeout of 35 seconds. (Since pushbullet sends a nop every 30 seconds.) If the timeout is hit, then the event-loop dies and the websocket connection is restarted. There are still some connectivity problems though. For instance, if the network is down and pb-notify is launched, then we get repeated `getAddrInfo: name or service not found` errors, as we expect, but if the network subsequently comes up, these errors continue rather than a connection successfully being established. I'm not sure why this is happening, but I suspect it has something to do with a networking library being used under the hood, as I've noticed similar behaviour in glirc2. Sometimes, doing a /reconnect on it doesn't work despite the network being up! Similarly, I get repeated DNS resolution errors there as well when the error occurs.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This should actually be configurable, so that you can choose exactly which notifications you would like to display. I'm thinking of a system of "notification policies" which are computations that determine whether a notification should be shown or not for a given event received in the stream. We can build an HTTP webservice into pb-notify so that policies can be changed dynamically, to (temporarily) silence certain types of notifications for instance.
The text was updated successfully, but these errors were encountered: