Hi,
during the last couple of weeks, the SAPO Messenger Mac client
implemented the Meta-Contacts XEP-0209. This is report of the issues
found. Sorry for the long email btw :).
1. The storage angle
The protocol is using private storage. I talked to one of the
authors, Kevin, that told me that a PEP-powered version will be
available sometime in the future. Using private storage is not a big
problem, except for the lack of notification on update.
With multiple resources connected, the other resource needs to be
notified somehow to re-fetch the meta-contact data. The workaround
that we used was a no-op roster push. Basically we set a roster item
(our own) with the same information that he has already. This roster
push is broadcasted to all resources and this signals the clients to
re-fetch the data. This is of course a hack, that only works with our
client, and the real solution is to move to PEP as soon as it becomes
available.
The second issue we found with the storage of meta-contacts is a bit
worse, and unsolved so far. This protocol will fail for servers that
don't support private storage. One such server is unfortunately
GTalk. So if one of your accounts is a GTalk acount, you cannot store
the meta-contact information.
The only workaround (and its not even complete) that I see for this
is if we relax the second point of the requirements. If we store the
full meta-contact data on all accounts, with a version attribute,
then we only need one of the accounts with private storage available.
If multiple representations get out-of-sync, we should use the most
recent (using the version attribute) one. I myself see several
problems that might happen when only a part of your accounts is
available, but they are no different than the ones with the current
spec in the same scenario. Even the current spec can get out-of-sync
between accounts.
2. Attribute selection
Each roster item has several "attributes" that a client keeps track:
the name of the contact, the groups it belongs to, the current active
avatar, and the current presence (status and show).
There are no clear rules on which of these we should use for the meta-
contact in case they differ between each contact. For now, we are
using this rules (but they can change at any time based on feedback
from our users):
1. name, groups and avatar: we use the name of the highest order
contact, even if he is offline.
this was done to minimize flash behavior (a contact changing
name, avatar or group) when we logged on. By itself it does not
prevent it, but its pretty close;
2. the presence (show/status): we use the first non-offline
presence based on the order of the contacts.
we used the "best" (aka most available) presence for a while,
but this *seems* more reliable for our day-to-day usage.
We don't support noneof the new PEP-based protocols. When we do, we
must also cross those with the meta-contact information to know which
ones to show the user. For example, if two different contacts inside
the same meta-contact announce different geo-locations, you should
a) use the most "recent" one;
b) use the one from the highest ordered contact;
c) talk to a hard-core physicist about the Heisenberg principle.
3. Attribute change
If we change the name of a meta-contact, what should we do to the
contacts inside?
Right now, we opted to rename all the contacts, but it is debatable
if this is not a excessive behavior.
This applies to any attribute change: name and groups.
4. meta-contact tag algorithm
The spec does not suggest any method of creating the tag attribute.
To ease our users to move to a XEP-0209-powered client, we opted to
use the following:
tag = sha1( lc(name) + apply( +, apply( lc, sort(groups) ) )
That is to say: concat the lower-case version of the name with the
lower case version of each group, alphabetically ordered.
This works very well if you already keep you contacts with the same
name inside the same group before moving to a meta-contact-aware client.
5. Final thoughts
I must admit that the lack of private storage in the GTalk service is
a big turn off for us.
If we are willing to loose the order attribute (and I would not like
that, but I want something that just works), there is a fallback
protocol that requires only the usual roster to keep meta-contacts.
If we assume that roster items with the same name + groups
(basically, if the tag algorithm above yields the same hash for your
roster entries) belong to the same meta-contact, we can implement
meta-contacts without the need of any extra storage, just the roster.
The two down-sides are:
1. you must rename the roster entries and stick them in the same
groups if they belong to the same meta-contact: personally I have no
problems with this, because it works pretty well even if I log in
with a contact without meta-data support.
2. you loose the user-order of contacts inside a meta-contact: so
you have to revert to the usual presence priority.
We used this method (client-side calc of hash based on the above
algorithm) in our windows client for 5 years now, with good results.
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: [EMAIL PROTECTED]
Use XMPP!
