Simon McVittie wrote: > It's currently unclear what will happen when a channel has > channel-specific handles (XMPP MUCs, in practice) and invitations happen. > > Assume [EMAIL PROTECTED], [EMAIL PROTECTED] and [EMAIL PROTECTED] are global > handles, and > [EMAIL PROTECTED]/Simon, [EMAIL PROTECTED]/Fred and [EMAIL PROTECTED]/Jim are > the corresponding channel-specific handles in the MUC [EMAIL PROTECTED] > > * If Fred invites me to join [EMAIL PROTECTED], will I see [EMAIL PROTECTED] > or > [EMAIL PROTECTED]/Simon in the local-pending set, or is it unspecified? > > * Also, will I see [EMAIL PROTECTED] or [EMAIL PROTECTED]/Fred in the members > set, or > is it unspecified? > > * When I accept the invitation and I get moved to the remote-pending > set, or if I'm trying to join a room without having been invited, which of > my handles will I see in the remote-pending set? (I assume it's the > same in both cases...) > > * If I invite Jim by calling AddMembers(RequestHandles([EMAIL PROTECTED])), > will I see > [EMAIL PROTECTED] or [EMAIL PROTECTED]/Jim in the remote-pending set, or is > it unspecified?
It's unspecified, but implementation constraints should mean that they all behave similarly. The main problem they all share is that you should not or anyone else should not be given a room-specific handle until they've actually joined the room, because until that's happened, you don't know if your nick is available in the room (in the case of us being invited), or you don't know what nick the 3rd party will take when they join the room (in the case of inviting others). Given this constraint, the most sane behaviour I can think of is that we should make the pending members (local or remote) always have global handles, and only issue the channel-specific handle when they become a member. Its quite likely that Gabble doesn't do this consistently/correctly, and in certain circumstances hypothesises a channel-specific handle which either we might not be able to obtain, or the invitee might not choose to. We could make things a little more consistent by specifying that when invites in rooms with channel-specific handles are accepted, the MembersChanged signal will report only the invited global handle in [removed], and the new channel-specific handle in [added]. Unfortunately, there's actually a situation where you can invite someone to an anonymous room and never clear their remote pending global handle because you never know what channel-specific handle they appear as. I don't think there's anything we can do about that. The alternative would be that we hypothesise a channel-specific handle for the pending invited people (us or them) and rename them when the invites are accepted. Without much thought, my gut feeling is that this would be even crazier. Thanks XMPP MUC. Thxmppmuc. > Simon Regards, Rob _______________________________________________ Telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
