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

[Julien PUYDT <jpuydt free fr>]

�ic Bischoff a �it :
> Le Mercredi 7 Juin 2006 14:23, Julien PUYDT a �it :
> > Yes, going back to the blackboard isn't the best way to achieve 6...
>
> You don't go black to the blackboard with no experience ;-).

Of course no :-)

> In pecular, I have been proposing a framework for address book "drivers" like:
>
> class EkigaAddressBook
> {
>         public:
>                 virtual gchar *name() const = 0;
>                 virtual const EkigaContact *firstContact() = 0;
>                 virtual const EkigaContact *nextContact() = 0;
> };

I don't like your first/next idea. If I take an XMPP roster in ekiga, 
connect to the same account from another program, and add a contact 
there, the XMPP roster will do a roster push, which your api doesn't handle.

A much better approach IMNSHO, when it comes to keeping track of a list 
of contacts, is the following pseudo-code api :
- get the current list of contacts ;
- notify/signal me when a new one appears.

There are two ways to handle the removing of a contact from such a list:
(i) either the book tells you the contact has been removed ;
(ii) or the contact itself tells you so.
Both can be handled by a notification/signal. My first tests used the 
second way to do so, but now I think the first is better : the signal 
tells you both the book and the contact.

> class EkigaContact
> {
>         public:
>                 virtual boolean hasName() const = 0;
>                 virtual gchar *name() const = 0;
>
>                 virtual boolean hasTelephone() const = 0;
>                 virtual gchar *telephone() const = 0;
>
>                 etc...
> };

Bad. :-)

First, you don't handle the case where several telephone numbers are 
available.

Then if you begin to put /everything/ in the *base* class, that will end 
badly. A base class should only have the most basic capabilities, not 
all of them.

> Comments and flames welcome.

As a last comment, I will repoint the two arguments I have to prefer a 
GObject solution to a C++ solution :
1) the GObject will nicely live and die in the glib mainloop, so we 
won't have gnomemeeting_thread_enter/gnomemeeting_thread_leave everywhere ;
2) exporting a GObject on DBUS is dead-easy, and DBUS will make ekiga 
more useful on CLI, GNOME, KDE and XFCE (alphabetical order, flame 
/dev/null).

Snark