[Standards] NEW: XEP-0209 (Metacontacts)
Etan S. C. Reisner
deryni at unreliablesource.net
Wed Jun 6 10:47:05 CDT 2007
On Wed, Jun 06, 2007 at 02:54:00PM +0100, Kevin Smith wrote:
> On 6 Jun 2007, at 14:22, Etan S. C. Reisner wrote:
> >On Wed, Jun 06, 2007 at 10:47:38AM +0100, Kevin Smith wrote:
> >>I imagine the most used implementation would be to show the
> >>metacontact in the group(s) of the primary contact, but any other
> >>rendering is equally valid, to my mind.
> >
> >Wouldn't that interpretation of the XEP basically forbid (or at
> >least make
> >non-deterministic) the showing of a buddy in multiple roster groups?
>
> Not at all; if the primary contact were in multiple groups, so would
> the metacontact be. One could also render the metacontact in all
> groups of member contacts.
I'm fine with that interpretation of this, my concern is with the 'only
show in one group' implementation which seemed to be what was intended and
seems to be what the other people in this thread seem to want and/or
already be doing.
> >Assuming a buddy is both in a metacontact (as a bare jid) and in
> >multiple
> >roster groups, which of the buddy list copies is to be combined
> >into the
> >metacontact? The first one we get from the server? The 'top' one in
> >the
> >roster group ordering? All of them?
>
> This is slightly confusing; each jid is only in the roster once,
> although they could be in many groups. Groups are a property of a
> contact, not contacts a property of a group. There are no 'buddy list
> copies', so I'm not sure this is an issue.
Yes, I'm aware of the relationship between contacts and groups. By 'buddy
list copies' I meant visual copies of the buddy, unless most clients don't
show a buddy in that has more than group in more than one group in the
buddy list window. Is that how most clients handle it? They pick one of
the groups and only show the contact in that group ignoring the others?
Or alternatively, does the metacontact apply per-group but in all groups
and thus this issue doesn't exist at all (which is a scenario I am
perfectly willing to accept).
> /K
-Etan
More information about the Standards
mailing list