[JDEV] Re: MUC problems

[Mats Bengtsson]

I'm sorry if this post is out of sync, but I get the digested version.

David Sutton:
>   On the other hand, the system of using an iq request, xmlns
>   jabber:iq:browse, to discover the room roster is not covered by the 
>   JEP. In order to maintain sanity, I have opted to continue using the
>   existing methods. If you require to see the real jid, and you are
>   allowed, then browsing the SHA1 resource will reveal the true jid. I
>   have to use the sha1, since it allows you to track the user more
>   consistantly - as I tried to explain before, I could use
>   'girls at conference.localhost/NICK' for the nickname reported by browse,
>   the problem is that if users swap nicknames, I have no way of knowing
>   that is what happened. The SHA1 string is unique to that user.

You certainly have a point here. It is a better solution to abstract away
the actual nickname so the conference component, and clients (!), can trace
a user independent on changes of nickname.
But, having three jids for a single user is just not a good solution.
Writing client libraries tracing three jids is not the optimal solution.
In principle, two jids are rewuired, the "true" and the room anonymous jid.

Somehow this situation must be clarified before I can proceed writing
client lib (JabberLib in Tcl). Although the MUC JEP does not discuss
exactly this situation, it must be more specific on how to handle
things related to jabber:iq:browse things.

More thoughts?      Mats