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

[Julien Puydt <jpuydt free fr>]

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

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

Snark