[Standards] DEFERRED: XEP-0209 (Metacontacts)
melo at simplicidade.org
Fri Jan 23 11:47:54 UTC 2009
On Jan 22, 2009, at 9:05 PM, Remko Tronçon wrote:
>> Thus, I consider the Kopete behaviour rather bad.
> I wouldn't call it bad. It's a good enough poor-man's metacontact,
> especially in the case where private storage is not available on the
> server. However, I do think behavior like this should be optional. I
> for example have a few contacts with the same name in my roster (but
> in different groups).
> Leapfrog provides both approaches IIRC.
All SAPO clients use this method. We hash the lower case versions of
the name and group name, and use that tag as a aggregation point.
If you move a new standalone jid in your roster to a meta-contact, we
rename the standalone JID and move it to the same group as the others.
This might seem bad for some, but it is in production for 6 years now
In the Mac version (Leapfrog), we implemented XEP-0209 and used it
internally (friendly customers and those brace enough to use the
nightly builds) but we rolled to the code back to the simpler version.
At the time, delays to retrieve the private storage items would cause
temporary mis-aggregation of contacts, who look like "bugs" or erratic
behavior. Also, the size of the iq set for each simple change to a
meta-contact is also a negative aspect of the protocol as it stands.
The final nail was that some popular XMPP services out there don't
have private storage. At the time, GTalk didn't have it, I don't know
if they have it now.
So we went back to our roster-based approach: its simple, works
sufficiently well (even with extra delays from rosters), and it is
immune to out-of-sync issues.
As others noted, it does rename contacts. For our user base, that was
a non-issue. We are mostly "home" customers.
XMPP ID: melo at simplicidade.org
More information about the Standards