Dear list, I am new to XMPP development and please excuse me in advance if this is not the good place to post my question.
I am developing a custom mobile (j2me) application that is going to use XMPP as it's "data" and "commands" transport mechanism. My implementation authenticates to the xmpp server and then retrives the user roster on each connection to the xmpp server before sending a new Presence stanza. The roster is stored / cached in the client after successful retrieval. Everything was fine until recently when I realised that a mobile device was constantly dropping its Internet connection for various reasons mostly loss of GPRS signal, incoming call etc ... With the actual state of the xmpp specs there is no other way for me than to re-authenticate and re-request the user's roster each time a connection is dropped. My main problem here is linked to the fact that data transfers over GPRS are still quite expensive if you're not on a flat rate data plan with your mobile provider, and I really want to avoid useless data transfers to limit the communication costs . I've been googling a litle and it seems that this issue has been discussed during one of the xmpp guru's meeting in Brussels earlier this year. A proposed solution was to implement a fast reconnect mechanism. I wanted to know what was the evolution on this side of the standards definition. More generally speaking, is there a way for me to bypass the entire post-authentication mechanism that is usually implemented i.e. roster retrieval. As far as I know roster retrieval is mandatory for a resource if it wants to be notified of new presence messages "If an available resource does not request the roster during a session, the server MUST NOT send it presence subscriptions and associated roster updates." The problem here is that I need the client to receive roster and presence updates even if the roster wasn't requested after re-authenticating to the xmpp server. Thank you in advance for your help and feedback on this. Best regards. Alex
