[Standards] Meta-Contacts: implementation notes
melo at simplicidade.org
Mon Apr 28 09:58:16 UTC 2008
On Apr 25, 2008, at 11:11 PM, Kevin Smith wrote:
> On Sat, Mar 29, 2008 at 8:44 PM, Pedro Melo <melo at simplicidade.org>
>> The protocol is using private storage. I talked to one of the
>> 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.
> Yep, but PEP where available is nicer.
Sure, no arguments there.
>> This protocol will fail for servers that don't support
>> private storage.
>> 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.
> Well, we can also set a 'master' account to look after servers which
> don't support a useful storage mechanism yet. This avoids getting out
> of sync between accounts, and allows us to cope until servers are
Sure but then you have to deal with different accounts available at
different times, each one with roster modifications.
How would you solve any conflicts? Of course you could ask the
client, but this is getting complex pretty fast.
>> 2. Attribute selection
>> Each roster item has several "attributes" that a client keeps track:
>> There are no clear rules on which of these we should use for the
>> meta-contact in case they differ between each contact.
> If the contacts are ordered, you pick the dominant order.
Always? What about presence <show>? Should we pick available over dnd
and away? should the order be used as the second level sort field
>> For example, if two different contacts inside the same
>> meta-contact announce different geo-locations,
> How is one person going to have two geolocs? :)
This is a topic for another thread: for PEP nodes that should be per-
user and not per-resource, how do we signal between resources which
one is the most representative of them.
>> Right now, we opted to rename all the contacts, but it is
>> debatable if this
>> is not a excessive behavior.
> That seems overkill, to me.
Well, it helps a lot if you later move to or temporarily have to use
a client without meta-contacts. But see at the end.
>> This applies to any attribute change: name and groups.
> It seems more than overkill for groups - it seems unhelpful.
See at the end. I think you and I have to very different views of
>> 4. meta-contact tag algorithm
>> The spec does not suggest any method of creating the tag attribute.
> Right, I think you can use what you like
>> 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
>> roster items with the same name + groups (basically, if the tag
>> above yields the same hash for your roster entries) belong to the
>> meta-contact, we can implement meta-contacts without the need of
>> any extra
>> storage, just the roster.
> It's a clearly inferior solution, but I don't see this is an awful
> workaround if people must use such servers - proxying another of your
> servers for storage seems a bit cleaner to me.
> Certainly, I'd get very irritated very quickly with any client which
> automatically renamed and regrouped my contacts for me. It irritates
> me enough when clients change my avatar automatically.
Maybe we have different views of meta-contacts.
XEP-0209 seems to me to be written in a way to minimize roster
modifications: you create a layer over your rosters, using the data
in 209 and try not to touch the original roster in any way.
This is one approach, but if this is the goal, then 209 is extremely
poor on meta-data. To prevent roster modification, you need to take
in account the name of the meta-contact, and probably the groups
where each meta-contact should be placed on.
Also without a clear set of rules on the interaction of a meta-roster
and the contacts order within with changing presence <show> and
probably <priority>, you'll never have interoperable implementations
*from the POV of the end-user*: the experience is largely based on
each implementation and not on the protocol used. This has good and
bad sides, but having seen the focus groups at work, I've become very
negative regarding people ability to deal with more than simple stuff.
Another approach is the one used at SAPO for a couple of years now.
Its clearly roster-based, and it modifies the roster a lot. If you
rename a meta-contact, all your contacts inside will get the same
name. If you modify the groups of a meta-contact, all the contacts
are set to the same group.
You can think that this is very invasive of your roster, and yes, I
used to agree with you. Thats why I pushed for 209 in recent builds
of SAPO Msg for Mac, because I placed myself in the shoes of people
that think like that. But after going through that experience, 209
created more problems than it solved. I think it does too little to
really solve the problem, and annoyed a lot of lower tech users.
Going back to think about this, I think our initial approach, of
roster modification, is better for our users: it's simpler to
explain, and when they use a client without meta-contacts, they can
still find their contacts, because they have the same name and are in
the same groups as the meta-contact. Plus, we use a protocol that we
know its available everywhere, jabber:iq:roster and it even plays
well with the recent 0237 roster sequencing XEP.
I will miss the order attribute in 209, but just not enough. I will
keep waiting for a real jabber:iq:roster annotation protocol :).
XMPP ID: melo at simplicidade.org
More information about the Standards