Hello Dave, Dave Cridland wrote:
> Well, that's true, but you just encode in whatever else makes sense > to relocate the session. > > We'd be using a node URI and session number tuple, probably. What if you resume twice ? You cannot implement session migration to the new node the user might be connected to, because the this sm-id is not updated during the life of the session. I still think requiring the full JID is the best approach as it maps with how to locate a session in the server when sending a message to a client. No extra mechanism is required to locate a session to resume than to locate it to send it a message. This is why I think this is much better. My original point is that this full JID seems needed for performance / scalability reason and we will need our implementation to require that. This looks like a small detail but when you deal with hundreds of thousands online users (and even more with millions), this is the kind of decision that pay off. -- Mickaël Rémond http://www.process-one.net/
