On Oct 6, 2008, at 5:27 PM, Jonathan Schleifer wrote:
Ok, I can understand your suggestions now. However, you're missing one point: What advantage do we get by a resource that has no meaing? IMO, nothing. A static resource just makes it easier for everyone, IMO. Replacing the connection, etc.
No it does not, because you don't want a connection replaced. you want a controlled take-over of an old session. You want a new connection to arrive and tell the server "Hey, I'm session-ID X and I want to take over it".
Abruptly taking over the other connection makes it harder for proper stanza re-routing.
Besides, we already know that some servers will not allow you to control the resource. Also, re-using the resource opens the previous discusses presence leaks problems.
IMO, you're suggestion to resume a session is really good, so the resource could get a session ID then. But until we have a XEP that does that, I'd like to keep it the way we have it and make it possible to use both - once we can resume sessions, clients that support that could ask for a random resource, while other clients still get a static one.
Sure. I said a couple of mails back, I have no problem that the bis RFC says something like "respect the resource the client sends". I was just arguing that it is a bad default, going forward, and we should move to a network where the resource is plumbing, non-visible to end users.
As I (hopefully) demonstrated in the past emails, all the current use cases (resource identification and capabilities) are better solved using Disco.
Plus I see one problem with resuming a session: You don't know what got lost. So we also need wide XEP-0198 implementation. Otherwise we can't resend on resume what got lost.
Sure: session resume requires link-level acks. Have you read 198? It talks about resumed sessions here: http://xmpp.org/extensions/ xep-0198.html#resumption
Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
