> I think that in the long term, we need to empower the server to do just > that. You propose that the client (or user?) should make the decision > what is important, by sending every push to the client. However, this is > bad for battery usage (you don't want your device to wake up on every > MUC presence change).
I don't propose that the client should make the decision what is important. Quite the opposite - server does. And *if* the server decides, that some event is important enough, it sends push and client wakes up. No need for additional levels of logic with different levels of push notifications importance, that indeed does put significant overheads on both clients and servers. > What's still not solved is how to interface that with E2EE (an encrypted > MUC message might or might not contain your name, demaning a push). Ah, this is simple. MUC message simply won't reach your server because your client is not connected to it. Unless, of course, you use some crutches to patch this unfortunate broken by design IRC clone. > In the short term, we should codify the rough set of guidelines in the > XEP, as suggested by Thilo and Daniel, and have high-priority and > background pushes. If by 'high priority' pushes you mean use alert-type push notifications in iOS, I'm opposing the idea of using them in at all. It's either bad UX or privacy breach, both are bad. -- Ненахов Андрей Директор ООО "Редсолюшн" (Челябинск) (351) 750-50-04 http://www.redsolution.ru _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
