Contacts, groups and renaming : the future in questions

[Julien PUYDT]

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

_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Eugen Dedu]

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

[Julien PUYDT]

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

[Damien Sandras]

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

---

_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list

[Julien PUYDT]

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

I had in mind something very very basic for the elementary chunks :
std::list<std::string> get_info (const std::string key) const;
(and of course Ekiga::LiveObject)

The real work would be for the merging object, with the following
merging algorithms :
- return the first answer ;
- return the union list of the answers (with duplicates are removed).

The first one could be used to implement the following method of the
merging object (Ekiga::Person?) :
const std::string get_name () const;
and the second to implement :
const std::list<std::string> get_groups () const;

That should be pretty easy to do and would already give the merging and
updating behaviour (that is : you see the merged information, and it is
updated live).

It's still not good enough if you want to add some information (ie: a
name which would hide the underlying name, new groups), but that's a start.

My main worry is the new gui.

Snark
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list@...
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list