I’ve developed a mobile IM client using Smack for Android (asmack). I realized that the login process takes up to 30 seconds on slow networks (e.g. GPRS/EDGE), which is not uncommon in my country. I was wondering if it would be effective to implement pipelining or something like XEP-0305: https://xmpp.org/extensions/xep-0305.html.
For example, can we just take for granted that the server will support starttls and send stream header+starttls in one packet, saving a roundtrip? Of course bandwidth would not benefit from this since the amount of data exchanged is still the same, but I’m sure the time that we can save is considerable. Of course errors would be handled accordingly (e.g. starttls not supported) by e.g. throwing an exception or just proceeding with login.
But since this is something that affects core functionaly, as opposed to adding simply another provider, it should be carefully considered how this is implemented. Keep in mind that we may have a GSOC project going and that we have the xep198 patch in the queue. This would be then the third change affecting Smack’s core. Ideally we handle one change after another, and the other two have more priority IMHO.
But of course nothing prevents you from starting coding right now. I sure will have a look at the commits and give feedback.
It think it would be pretty risky to incorporate an experimental spec into the core.
I think your best course of action is to extend the XMPPConnection with this customized behaviour. Thus making your own QuickStartConnection.
XEP-305 is, besides a few exceptions, mostly recommendations, that can be safely applied.
One excecption is feature:pipelining. I think it may be possible to make the use of this feature optional within XMPPConnection. So it can be enabled for testing purposes. I don’t think that it’s implementable as subclass, as most of it happens in the connect stage.
Sorry to wake a sleeping thread up.
I just wonder, whether Daniele has been contribute this XEP-0305?
Or this has been an official feature of smack 4?
Just in order not to reinvent the wheel, because I have quite the same purpose.