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



�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





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]