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

[Damien Sandras <dsandras seconix com>]

Le lundi 19 octobre 2009 à 17:06 +0200, Julien Puydt a écrit :
> 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)

It looks good.

What about the API proposal you have in mind ?
(a basic draft about the various classes that will be involved is enough).

---

	Damien Sandras
	http://www.ekiga.org http://www.beip.be

---