вт, 3 сент. 2019 г. в 17:14, Philipp Hancke <fi...@goodadvice.pages.de>:
> 0353 was explicitly designed for push (by not including the full payload > due to size constraints) in conjunction with 0357 and should not go to > MAM (hence no body). > > This has some sad consequences like the lack of a message acting as a > call data record in the users history. > We're using Processing hints <store> element to make an archive store such messages. https://xmpp.org/extensions/xep-0313.html#hints > The way 0353 is supposed to work is: > 1) you are offline but have a push-enabled client > (there is the more interesting scenario where some clients of yours are > online but none does jingle... and you would need to send a push > notification to your offline client that does... that is a generic issue > however) > 2) you get a push notification with the <propose/> element and know the > senders full jid, the session id and (FYI) the media types involved > 3) your client requests that session at the sender. If that session > doesn't exist anymore the sender will respond with a message stanza with > type=error and <item-not-found/> (and potentially the jingle > <unknown-session/> > No, I think push notifications do not work the way you describe. XEP-0357 says that a published <notification/> MAY contain additional custom information, however, all our implementations of Push notifications assume that NO additional information is relayed through third-party services (ejabberd, as I recall, doesn't even support publishing such additional information). Thus, we get NO <propose/> in push notifications, NO message text, nothing. Just notification to an app that it should wake up and update its data. Consequently, the only ways we can get this information are MAM and offline messages/ Since offline messages perform poorly when there are multiple user devices, it leaves us with just MAM. I strongly oppose any suggestions to make push notifications work differently. If we start sending payload about calls via FCM/APNS, why stop at calls? We can just send full message text via push notifications as Telegram does. And at that point, why messing with XMPP at all? An FCM-only messenger can be coded in a week, it'll send and receive full message text via FCM, store messages on FCM cloud database and all will work admirably well. -- Andrew Nenakhov CEO, redsolution, OÜ https://redsolution.com <http://www.redsolution.com>
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
