Re: [Ekiga-devel-list] Contacts, groups and renaming : the future in questions

[Julien Puydt <jpuydt free fr>]

Eugen Dedu a écrit :
> Julien Puydt wrote:
> > Hi,
> >
> > here are some thoughts on the merged contact+presentity system we want
> > in ekiga 4.
> >
> > The main idea is the following : with the current code, you choose a
> > contact in the evolution addressbook and copy some of it over to the
> > roster. This works pretty well, but has a few consequences : what if you
> > rename the contact in evolution? Or change precisely the phone number
> > you pushed to the roster? The current code just doesn't keep track of
> > the changes : you have to edit the name and the phone number in the
> > roster again (first time was in evolution).
>
> Isn't better to just store "links" to sources instead of copying them
> into the roster?  The ideal thing is that there is a server, evolution,
> storing contacts, and all the other applications which only point to
> them.  Thus, when you modify a contact, all the applications see the change.

That's exactly what is planned.

> > So we want to keep track of where the informations came from, so we get
> > notified when they get updated. And we want to be able to "merge" those
> > informations like this : we want a user who knows, say Damien through
> > ekiga.net (SIP) and through jabber.org (XMPP), to be able to join both.
> > That's doable, and I already made some changes to ease things.
> >
> > But this organization has a few problems which I would like to discuss.
> > Let's imagine I have a contact "Mr Doe", which I know through :
> > - a read-only XCAP server, where he belongs to both the "Foo" and "Bar"
> > groups ;
> > - a read-write XMPP roster, where he belongs to both the "Bar" and "Baz"
> > groups.
> > We have in effect three contacts :
> > - the elementary XCAP contact ;
> > - the elementary XMPP contact ;
> > - the merged contact.
> >
> > Here is now a list of questions, with the answers how I see them :
> > (*) should we allow renaming the XCAP contact? No.
> > (*) should we allow renaming the XMPP contact? Yes.
> > (*) should we allow renaming the merged contact? Yes, but that name will
> > then hide the other two names, and hence won't get updated anymore.
> > (*) should we allow renaming the "Foo" group? No.
> > (*) should we allow renaming the "Baz" group? Yes.
> > (*) should we allow renaming the "Bar" group? No.
> > (*) should we allow removing the XCAP contact? No.
> > (*) should we allow removing the XMPP contact? Yes.
> > (*) should we allow removing the merged contact? Yes (though that can
> > become hairy).
> > (*)
>
> I do not know these protocols, and maybe my idea is wrong, but:
>
> There are two groups, local and distant ones, linked together.  Local
> group name is copied/initialised from the distant one, but it can be
> changed afterwards.  Maybe the same for user names...

Well, that's what I had in mind for the name, but there's a little 
problem to do the same for groups : they're not a single string, they're 
a list.

So if we go the "the list on the merged contact+presentity hides the 
list of the elementary contact+presentity members" way, then when the 
user adds our contact+presentity to a new group through another mean, 
then ekiga won't update that anymore.

And if we go the "the list on the merged contact+presentity adds itself 
to the lists of the elementary contact+presentity members" way, then:
1. you still haven't decided what you allow on the groups which appear 
in several elementary contact+presentity ;
2. when you have an elementary contact+presentity in a "Bingo" group, 
with a merged contact+presentity in a "Bingo" group and you allow 
renaming that last one... the user renames to "Sigh", and the 
contact+presentity ends up in both "Bingo" and "Sigh"...

Hope I'm clear :-/

Snark