As a sidenote, I’d rather not mark the service as a foreground service by using a foreground notification. If the system kills it, it has its good reasons. I just want to have an opportunity to save my messages or got them redelivered if I couldn’t make it.
Really no real alternative to this instead of adding yet another XEP? I need to add one more module to the server (more server load), one more extension in the client (more client load + bandwidth + requests initiating from the client), instead of using the already very well working offline messages mechanism.
Besides, I don’t think it’s a wrong approach to add a listener there IMHO. XEP-0198 states:
“[…] until a stanza has been affirmed as handled by the server, that stanza is the responsibility of the sender (e.g., to resend it or generate an error if it is never affirmed as handled by the server).”
Since SM acks work both ways, I assume this sentence is valid also for clients.
I can provide a patch if you can tell me you will approve it
Perfect valid argumentation if you don’t need MAM. I haven’t made up my mind entirely on this. Maybe I could be made configurable when Smack will count the Stanza. I’ll come back to you in a few days. You could prepare a small patch in the meantime, showing me what you would change.
Instead of forking the whole library, I only took XMPPTCPConnection, removed the deferAndBundle parts because they required protected access to other classes, and modified it a bit. It could be done better I know, but as I said I just wanted the feature I needed with very few code modifications.
In the same page you can see my class KontalkConnection overriding the processPacket method which now suspends ack replies until another class resumes it.