Fernando Padilla wrote: > Ok. What's a "session context" in your mind (for future reference)?
The client establishes and holds a connection with the server. Every such connection opens a Session on the server. For every session, the server holds an session context object which keeps information about the session. While processing a stanza sent from the client, this context object is available to the handlers. > I was just trying to clarify.. Someone was complaining that they could > not get a "from" attribute for a stanza sent to the MUC component from a > client (some reference to Smack being brought up). And in my mind that > would be a bug in the server for not adding the "from" attribute. :) The one complaining was me. An integration test for MUC is currently failing. And you are right. It's a bug in the server, because we do not yet fully implement RFCs 3920+3921. Related issues that are preventing MUC from working properly: http://issues.apache.org/jira/browse/VYSPER-181 http://issues.apache.org/jira/browse/VYSPER-176 http://issues.apache.org/jira/browse/VYSPER-6 Bernd > > > On 8/25/09 10:27 AM, Bernd Fondermann wrote: >> Fernando Padilla wrote: >> >>> >>> On 8/25/09 6:24 AM, Niklas Gustavsson wrote: >>> >>>> If the client send a full JID, that is true. But, as in the case of >>>> Smack, the client might not send a "from" attribute at all, in which >>>> case we will need to figure out a resource anyways (not sure yet what >>>> the best way is or if the spec says this somewhere). >>>> >>>> >>>> >>> Just a question. Isn't it the server's job to add the "from" >>> attribute? Not the client? So shouldn't Vysper be adding the "from", >>> when it first receives the stanza on the originating connection? >>> >> You are right. And the server does exactly that, but only in case the >> stanza leaves the session context, and the FROM is no longer trackable >> from that. Yet often the stanza either never leaves the session context >> (e.g. disco IQs), or results in new stanza being sent (presence). >> >> >> Bernd >> >
