Hi,
On Apr 3, 2008, at 8:52 AM, Remko Tronçon wrote:
For more than 5 years now, this is being used in production at
SAPO. If
several contacts have the same hash (based on the algorithm above)
then the
client displays them in the same meta-contact.
This poor man's metacontacts approach could be enough, indeed. I don't
really understand yet why you would do the complex hashing thing, I
would just (optionally) group all contacts with the same name within
the same group into one metacontact. This would mean that, if one of
the sub-contacts is in two groups, it would be in a meta-contact in
one group, and be separated in the other. As far as I understand, with
your approach, it wouldn't be in any metacontact at all?
The hashing is a mere implementation detail, actually. As long as you
specify the you must compare the lower-case versions of the name and
the groups (in a specific order) it will work out ok.
I don't like the term lower-case. I prefer some sort of case-ignoring
stuff, but I'll leave that for native speakers to sort out. The point
is to compare ignoring case.
As for the difference in group membership given rise to two meta-
contacts, yes, it would.
Right now, I don't have a strong opinion against your way of doing
things, but in your scenario, it seems to me that each meta-contact
is a per-group entity. So a single roster item could belong to
different meta-contacts, if he belongs to several groups. This is a
problem for me in two situations:
* renames: if I rename one meta-contact, I need to rename the
roster items that belong to it, and this will undo the meta-contact
in the other group;
* group-less roster displays: if your client has an option not to
display groups and just bunch the contacts in a single list, ordered
by some metric like <show> or other complex rule, then you get N meta-
contacts, one per group.
In the end, I still prefer to have a strict rule (name and groups
must match). I think a more loose rule like yours will open up
problems when you start to think about renaming and stuff.
Things become more complex when you stop displaying the roster name to
the user, and only display the names that the user assigned to himself
(nickname xep). Maybe in that case, you would have to make sure that
the roster name is something sensible initially, and you create
metacontacts by dragging & dropping contacts on each other, which as a
result would rename the contact to the item you dragged onto it. The
user would never see the actual assigned 'names' in his client, but
they should be sensible because other clients might show it.
I like to show the nicknames and other info the contact has chosen
with lower priority to my client, to prevent spoofing attacks. The
user (my client user) will see the information that he chooses (name,
group), and optionally, in lower contrast colors, information under
the contact control.
If I give too much relevance to the user nickname or other
information in control of the contact, then I think we are opening up
a lot of avenues of attack. Just showing the avatar is problem enough.
I think clients would be better off showing that information as a
"More information"-pane at the time of subscription and in context-
menus, but ask the user to choose the name for the meta-contact.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: [EMAIL PROTECTED]
Use XMPP!
