Hi Michael, On 20 January 2014 18:25, Michael Weibel <michael.weibel+x...@gmail.com> wrote: > Hi all, > > We currently have an interesting discussion about the various compromises we > did with the implementation of Candy (MUC client in javascript) in part of > the refactoring issue I started > (https://github.com/candy-chat/candy/issues/207). > > Currently Candy works with the semi-anonymous room jids > (r...@conference.example.com/nick) to send messages. We use this approach > also to send direct messages to other occupants in a room. > However, as Hypher, one of our users, mentioned, this is not the standard > behaviour of XMPP clients and therefore he has some issues with the use case > he wants to use Candy for (in-game chat).
I wouldn't say it's not the standard behaviour of XMPP clients. In fact the only client I can think of that will use real JIDs for private messages in rooms is Pidgin (and, well, I think Adium too - but they share a lot of code). As a user I find this behaviour extremely irritating. People who are not on my roster message me, I don't know their nick or what room they came from, and if their server doesn't allow messages from non-contacts I also can't reply back to them. I can't see their presence, and I might not want to add a stranger to my roster just for one chat. I personally think if you start a message with a room occupant in the UI, the protocol should do the same, converse with that occupant in that room. If I have a chat open with someone already, I am generally unlikely to open a second chat with them in a room we are both in (unless I forgot about the first one perhaps). This approach is always going to work, it is consistent from the user perspective (sometimes JIDs are available, sometimes they are not...), and so on. Regards, Matthew _______________________________________________ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org _______________________________________________
