On Mon, Aug 17, 2009 at 09:55, Niklas Gustavsson<[email protected]> wrote: > I'm might be a bit slow here, so have patience :-) > > On Mon, Aug 17, 2009 at 9:25 AM, Bernd > Fondermann<[email protected]> wrote: >> It's only that the server in general (with or without MUC doesn't >> matter) doesn't currently handle directed presence stanzas from the >> client. >> Think of it as if it wouldn't handle unavailable stanzas. Then, MUC >> wouldn't receive notice when a user goes offline. >> >> It works like this: >> 1. Client sends presence to server ("outbound" in the notion if the RFCs). >> 2. server (the client's server side session) handles the presence and >> looks what to do with it >> (in this case: it's directed presence => throw not implemented exception!) >> 3. server routes the stanza (locally, to another client or to >> component, or to another server). >> even if it's only routing server-locally, the stanza is now "inbound". >> 4. server handles "inbound" stanza and forwards to MUC. > > When exiting a room (which would be the same thing as going offline in > MUC), the client would send: > <presence > from='[email protected]/res' > to='[email protected]/nick' > type='unavailable'/> > > This will be picked up by the MUC module, without going through the > regular presence handling.
No, this is not how it's intended to work and how it will work, if you are not talking about the "inbound" case. I tried this "outbound == inbound" approach for a long time and you cannot possible make it work, because they have different semantics. The stanzas goes through the server two ways, once from the client to the server (outbound handler), then back from the server to MUC (inbound handler) in your case, and from server to client in other cases. One reason for this is that the client's session on the server MUST keep track of all (outbound) directed presence stanzas. You cannot possible do this within a MUC-specific handler. Trust me, you are missing an important point about the XMPP protocol and how Vysper works (should work). > Meaning, the stanzas would not go into step > 2-4 above. Instead, the MUC module would get the stanza before 2 since > it will get all stanzas destined for "chat.vysper.org". Maybe this is > the wrong way, but I think it's the way it currently works. We have to change that. The MUC specific use case is that it receives _inbound_ presence stanzas directed at "chat.v.o". They are "directed presence"s because the two communicating parties (client and MUC) have no established and persistent subscription relationship. They connect "on-the-fly" as far as presene is concerned. An example why it does not work the short way: Say we have chat.vysper.org, but no user's on the v.o.-domain whatsoever. Now [email protected] wants to participate in a chatroom. He sends /outbound/ directed presence to "chat.vysper.org". jabber.org receives the d-p stanza, records the fact and forwards to vysper.org server. The vysper.org server now receives the /inbound/ d-p and routes it unchanged and unprocessed to chat.vysper.org for further handling. The chat (currently a monologue, but anyway) can start. Now [email protected] goes away. No more messages flow. How would chat.vysper.org receive notice? Well, pretty easy. jabber.org becomes aware of the fact that me's session ended, so he sends unavailable stanzas to all d-p contacts and discards them, because they have to be re-established on next login. To make this work, outbound d-p cannot go directly to MUC, even if the client is a local user. > In addition to this, the MUC module needs to be informed of the users > going offline without sending this stanza, e.g. the socket dying. This > is currently not handled by MUC. Handling d-p relationships is solely the client's servers responsibility, not MUCs nor the client's, or that of any other extension or component. Further references: http://tools.ietf.org/html/draft-ietf-xmpp-3921bis-00#section-4 To better understand how a presence stanza travels, look into (and step through probably) PresenceHandler. It's the most complicated part of Vysper, and this is for a reason. (And yes, I feel sorry about that ;-) We lost one committer on Presence.) Bernd
