Niklas Gustavsson wrote: > On Mon, Aug 17, 2009 at 12:27 PM, Bernd Fondermann<[email protected]> > wrote: >>> In the federated case where a jabber.org user logs in to >>> chat.vysper.org this would still work with the current code. >> There is no way for a jabber.org user to log into vysper.org in XMPP. >> He can only log into jabber.org and send stanzas via his homebase server. > > Sorry, that's me using the incorrect wording. By "logs in" I mean "enter > room". > >> By putting the stanza on the 'inbound' queue. > > I still don't understand how StanzaHandlerLookup would be able to > understand that this should not go to PresenceHandler again. Or maybe > we need to change StanzaHandlerLookup to be able to distinguish > between outbound and inbound stanzas and provide different handlers?
ok. now there's a point. in/out-bound is only determined in the PresenceHandler. Let's take a step back. Say there is no conference.vysper.org. How would MUC work then? MUC would behave as an in-server session, which can be addressed like any client session can. A client sends directed presence to [email protected]. How would MUC receive this stanza? My answer is, that the server would (have to) know where to route the inbound stanza. This illustrates both the outbound and inbound step in handling. But instead, in this case, the server routes to the component only _after_ the outbound handling took place. This would happen in the StanzaRelayBroker, where federated inbound stanzas will appear. That's where I think would be the right place to route to MUC. Is that too confusing? What I want to say is that routing to a component should happen after outbound handling. This is possible for full JIDs (like [email protected]) currently, and should be for component.vysper.org, too, in a similar fashion. Bernd
