5 ms·
Having each app run in the background and manage its own notifications can work, but also causes battery life issues with more apps.
by snazz 5y ago
Having each app run in the background and manage its own notifications can work, but also causes battery life issues with more apps.
- rubatuga 5y agoI mean, if you just have a select() command blocking, I don't see why having a 100 sockets open would be any different than 1 socket.
- detaro 5y agoYou need to keep the connection alive, which means regular traffic, which means regularly sending data, which needs energy. More connections mean a) more traffic and b) unless you add some coordination mechanism, waking up the modem more often at random times, which is energy-intensive in itself.
- rubatuga 5y agoI see, we need some coordination mechanism, and at that point, why not just use a central server to manage notifications :)
- zozbot234 5y ago> unless you add some coordination mechanism, waking up the modem more often at random times, which is energy-intensive in itself. You just need to coalesce timer wakeups, which Linux supports already at the kernel level AFAICT.
- ryukafalz 5y agoPart of the problem is that Linux desktop apps typically aren't designed to conserve on network usage and/or don't have mechanisms to do so without a push server. For example, Matrix clients on Android/iOS will stay suspended entirely, then will wake up when you receive a push notification. Desktop clients, on the other hand, will stay running and receive every message, even if they're not messages that you necessarily care about/that would notify. The protocol could in theory have an in-band way to tell the server "hey, I really only care about notifications now, could you only send me those?" but currently it doesn't. By contrast, most Android/iOS apps can rely on push notifications and suspend completely when they're not in the foreground - meaning they're not receiving anything but what's important enough to notify about.
- aidenn0 5y ago> For example, Matrix clients on Android/iOS will stay suspended entirely, then will wake up when you receive a push notification. Doesn't the protocol already need to do something to support that? Presumably it's an out-of-band notification, and they needed to add support for that. If they already added FCM an APNS, they'll have to add something to support a 3rd OS. It could be in-band or out-of-band, but either way sending a message on a TCP connection is really all that is needed. As a side note, Jabber did add an in-band way as you suggest, but then also had to add OOB signalling because Apple disallows open sockets for background apps.
- ryukafalz 5y ago> Doesn't the protocol already need to do something to support that? Presumably it's an out-of-band notification, and they needed to add support for that. Yep, it does, so you could do this; the problem for the Linux desktop is just that there isn't a standardized out-of-band push notification system yet. (I saw another commenter mention UnifiedPush, which sounds interesting - in any case it's not widely supported yet.) > As a side note, Jabber did add an in-band way as you suggest It's been a while since I looked into this in detail, but IIRC Jabber generally doesn't have a server-side way to determine which messages should notify? As I recall, the protocol was designed with smart clients and dumb servers in mind, though I'm sure some of that has changed over time - but that design decision doesn't lend itself as well to clients on battery-constrained devices. Although with that said, the fact that you aren't required to be in the same set of MUCs on every device helps in battery-constrained devices; for example I only stay joined to the rooms that my friends are in from my phone, unless I need to join another one temporarily.
- iudqnolq 5y agoThe radio is a massive battery draw, so you want it to be off as much as possible. The built-in push notification service will batch low priority packets and send them all alongside the next high priority one it receives.