On 1/29/10 4:09 AM, Pedro Melo wrote: > Hi, > > > On Fri, Jan 29, 2010 at 4:22 AM, Justin Karneges <justin at affinix.com> wrote: >> Any sent stanza acts as a probe here, at least for discovering s2s connection >> errors. If enough time passes in a room and nobody has joined, changed >> status, left, or sent a message, then it's probably not unreasonable to >> suggest that all of the participants be sent /something/ to induce a bounce. > > Agreed, but /something/ need not be a presence probe, given that you > would be asking the wrong question. > > With a presence probe you are asking "are you still online?", but what > you want is "are you still connected to this room?". > > Having said that, I don't see how probing a full JID is more > problematic than probing a bare jid. Because no servers do that now and it's not clear to me how they would handle it. > The risk that Peter mentions of > pooling presence status is present on both cases. Right, your server could always poll on your behalf, although that is not the way servers work now (and it seems that we might want to discourage that behavior in the text). More fundamentally: what is the problem we're trying to solve here? If it's only MUC ghosts then I think we can address that in XEP-0045, which is currently being reviewed on the muc at xmpp.org list. If it's a broader problem with directed presence as such, then let's figure out what the problem really is. One point about directed presence that came up recently is the fact that after I send you directed presence, my server will not send you subsequent presence updates that I generate, it will send you only my unavailable presence at the end of my presence session. That means my client needs to directly send you the interim presence updates. Is that a problem we need to solve? It seems simpler for the server to send you my interim presence updates, and that might help with directed presence in general. But I'd like to be clear on the problem before saying that probing full JIDs is a good idea. Peter -- Peter Saint-Andre https://stpeter.im/
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.