[Standards] About Fast Reconnect

[Peter Saint-Andre]

On 05/05/2008 4:31 PM, Fabio Forno 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 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.
> 
> Basically stalled. 

I prefer "unintentionally delayed". :)

> However a standard is just a first step, then you
> have to wait for server support, and time will pass. 

Correct.

> The only working
> solution for these things now is a BOSH connection manager that keeps
> the session alive also when disconnected.

For the foreseeable future, I think that's right.

> 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.
> 
> 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.

Right.

And perhaps roster sequencing will help here, too.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20080508/b06bd378/attachment.bin