Re: [GnomeMeeting-devel-list] Refactoring the addressbook code

[Julien PUYDT <jpuydt free fr>]

Damien Sandras a écrit :
> The address book has to stay. It is a way to store local contacts, and
> to find new "remote" contacts using LDAP or any other mean. 

Yes, that is what was settled.

> Each contact belongs to groups. Each contact can even belong to several
> groups using Evolution.

Indeed.

> We would need to add a specific group. I do not have a good naming, but
> let's call that group "ERoster" for now (Ekiga Roster).
>
> When the user adds a contact to the address book, that contact is
> identified by an URL. That URL can be H323, SIP, XMPP or anything else.
> He can add the specific contact to the ERoster group. (We need to find
> an intuitive way of doing this. A simple check box "Part of the roster"
> might be enough).

I don't agree here : you're basically making the roster flat (ie : no 
groups in the roster)! I'd rather see the roster become a real 
addressbook, with groups being what ekiga now names "categories".

> In the main UI, we have a Roster. That Roster displays all contacts from
> the address book who are part of the ERoster group of contacts. They are
> organized in groups, depending on which groups you have associated them
> to in the address book (Family, Friends, ...). If we know that we can
> have presence information, then we subscribe to presence events, and
> update icons in the Roster. If not, the user is still visible, but
> without presence information (eg: "Mom" sip:+32497973131 ekiga net).
>
> Editing the Roster will bring the same popups than editing contacts in
> the address book.

I would like to avoid tying the ui to ekiga : there *must* be a clear 
separation between the backend and the ui, so the dbus component doesn't 
play second-class citizen :-/

Notice that for the ui, gaim already has it, and it is easy to write a 
prpl (protocol-plugin) for it that would show ekiga's roster.

> That is not complex to do. However, I wonder, is there some GOOD roster
> Widget that we can reuse, or not? No need to reinvent a Roster if there
> are good ones available.

There is quite good roster ui code in gaim & gossip. Gaim's ui could be 
used through dbus, and the gossip ui comes as gobjects so we could 
"steal" it easily.

> I also have great ideas for the UI, but I'll leave the surprise for
> later :-D
> I will start working on the UI after 2.0.2 has been released. Because
> even if we do not have presence information, having a roster with
> contacts you call often is far more convenient than going into the
> address book each time.

Yes, having a simple roster, then adding presence capabilities is the 
way to go. I would say :
1) create a simple roster backend ;
2) export it through dbus to use gaim's ui ;
3) add our own ui to ekiga ;
4) add presence to the roster backend ;
5) upgrade dbus to export the presences ;
6) upgrade ekiga's ui to show the presences.

Snark