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
([email protected]/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).
When we initially developed Candy, we had to make the decision whether to use
the real jid of a user to send him a private message or to use the room jid. We
decided to use the room jid because it’s much easier (without roster
accept/declines) to display a user whether he’s still online or not. The
tradeoff however is, that user A can have two conversations with user B (we
have also some other issues with it, but they it’s root in this decision).
Now what I would like to hear is your opinion about Candy’s behaviour and also
what you think how we could solve the issue to (A) use the standard behaviour
and (B) to be able to display a users’s online status.
While we could for sure send roster requests and auto-accept them in case one
wants to talk privately to another user, I don’t think this is a good behaviour
because people might not want this.
Also if we would change to always use the real jid of users, what would it mean
for anonymous users (which a lot of our users use)?
Thanks,
Michael
_______________________________________________
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: [email protected]
_______________________________________________
