3 ms·
I should have made the link to the document on XMPP on Mobile Devices more explicit: http://xmpp.org/extensions/xep-0286.html http://xmpp.org/extensions/xep-028
by ralphm 13y ago
I should have made the link to the document on XMPP on Mobile Devices more explicit: http://xmpp.org/extensions/xep-0286.html http://xmpp.org/extensions/xep-0286.html. In short, the use of compression in the TLS layer negates the oft stated verbosity of XMPP. It really isn't the problem you think it is. More info: http://stpeter.im/journal/1384.html http://stpeter.im/journal/1384.html. I might be a fanboy, but I do know what I'm talking about.
- tytso 13y agoCompression doesn't help CPU utilization, which in turn doesn't help battery consumption. In addition, if the protocol is "chatty" (i.e., sends lots of packets even if there isn't any communication going on -- say, when users change their status/presence information, for example) it means waking up the CPU, which in turn means less power efficiency.
- ralphm 13y agoPlease read that first document and also my remark about SIFT, which basically allows for delaying or dropping presence to cut down on antenna use and battery consumption.
- dwdbah 13y agoHmmm... As the author of XEP-0286, I think I ought to chip in a bit. 1) Compression does help keep the transmissions under the FACH threshold on most networks. This more than outweighs the CPU cost. 2) The bulk of the data to be compressed isn't XML, but text. 3) The chattiness of the protocol - ie, transmissions that are not needed at that point in time - will indeed change radio states, but not only did Google tackle this problem privately, but the XSF has also looked at it in detail. 4) Really, the CPU is a non-issue here. It's all about the radio power states. This is likely to be entirely different at the server end, however efficient XML parsers can and do exist to mitigate this, and make it more distributable.