[Standards] About Fast Reconnect
azlist1 at gmail.com
Tue May 6 00:29:34 UTC 2008
Thank you Fabio for your answer.
>From your answer I guess I could donwload the roster once every X hours or
so ... and if my j2me client drops connection to the xmpp server, just
reconnect, authenticate, send my presence, without requestiong roster. I
believe this would fasten up things a lot and make the auth / post-auth
process much lighter. .
What do you think ? Am I missing something else here ?
Thanks again for helping.
On Tue, May 6, 2008 at 12:31 AM, Fabio Forno <fabio.forno at gmail.com> wrote:
> On Mon, May 5, 2008 at 4:53 PM, az lists <azlist1 at gmail.com> wrote:
> > I've been googling a litle and it seems that this issue has been
> > 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.
> Basically stalled. However a standard is just a first step, then you
> have to wait for server support, and time will pass. The only working
> solution for these things now is a BOSH connection manager that keeps
> the session alive also when disconnected.
> 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
> > does not request the roster during a session, the server MUST NOT send
> > presence subscriptions and associated roster updates." The problem here
> > that I need the client to receive roster and presence updates even if
> > roster wasn't requested after re-authenticating to the xmpp server.
> It's about presence subscriptions, not general presence. If you don't
> download the roster you are implicitly saying that you don't want to
> handle it, so any update is filtered out.
> Instead you are still able to receive presence, just send your own first.
> Fabio Forno, Ph.D.
> Bluendo srl http://www.bluendo.com
> jabber id: ff at jabber.bluendo.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards