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 ________________________________________________________________________
<<attachment: ekigacomplexicon32.png>>
_______________________________________________ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
