On Thu, Mar 11, 2010 at 10:31, Bernd Fondermann <[email protected]> wrote: > On Thu, Mar 11, 2010 at 09:51, Bernd Fondermann > <[email protected]> wrote: >> On Thu, Mar 11, 2010 at 09:06, Jean-Sebastien Delfino >> <[email protected]> wrote: >>> With ejabberd and gtalk (and IIRC jabberd too), if I send a message to >>> [email protected] for example, and jdoe is listening through multiple client >>> resources, like [email protected]/desktop, [email protected]/laptop, >>> [email protected]/phone, he'll get a copy of the message on each resource. >>> >>> From what I can see in my test environment, Vysper seems to behave >>> differently and only delivers the message to one of the connected resources. >>> >>> Is there a way to send a message to all connected resources like the other >>> servers do? or did I miss anything in the way I've constructed the >>> XMPPServer [1]? >> >> Looking at the code, this is the way it's implemented. >> However, you could send a <message type="headline" > and this would go >> to all resources. >> >>> >>> I've checked the XMPP specs: >>> >>> XMPP Core - RFC 3920 Section 10.5 [2] says >>> 'should deliver the stanza to at least one of the connected resources' >>> >>> XMPP IM - RFC 3921 Section 11.1 [3] says >>> 'MAY choose between them or MAY deliver the message to all such resources' >>> >>> Then XEP-0259 [4] introduces a protocol extension allowing device resources >>> to control which one should receive the messages. >>> >>> So, I'm not an XMPP expert... but unless Vysper implements XEP-0259 -- or >>> another relevant XMPP extension from this spec maze :) -- I think it would >>> make sense to send the message to all connected resources (unless they have >>> indicated a negative priority, as described in [3].) >> >> ... unless of course you send to a resource directly. >> >>> >>> Thoughts? >> >> I'm undecided. I'll go and figure. > > see > http://xmpp.org/internet-drafts/draft-ietf-xmpp-3921bis-05.html#rules-barejid-resource-message > and VYSPER-179 > > We really have the choice. Means we should give users the choice and > make it configurable. > After implementing the functionality, of course :-) > Also, what is not working properly right now is how the prio > resolution tie is resolved. > > I'll have a look.
In trunk, should now work as you suggested. Bernd
