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

[Eugen Dedu <Eugen Dedu pu-pm univ-fcomte fr>]

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.

> 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...

> I made slight changes to the current which make it possible to easily
> modify the existing code to have nice elementary contact+presentity.
> It's not done but it's reasonably there.
> 
> I'm a little unsure if my ideas for the merged contact+presentity, so
> didn't code them yet (though it is my hope that it would be simple).
> It's definitely still at the drawing board stage, but shouldn't be
> difficult or long once we know what we want to do.
> 
> It's pretty clear the current gui won't be good enough to deal with the
> new organization : it should be able to show the merged
> contact+presentity objects organized in groups, and allow unroll/roll
> operations on them to look at the specific elementary contact+presentity
> objects within. And of course, I guess we will want easy drag'n drop.
> This will be hard and long, especially since I'm definitely not gifted
> when it comes to gtk+ work.
> 
> Comments welcome (especially if it comes with code for the gui)


-- 
Eugen