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

[Éric Bischoff <ebischoff nerim net>]

Le Mercredi 7 Juin 2006 17:57, Julien PUYDT a écrit :
> 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.

I am not sure that the Evolution, LDAP or KAddressBook drivers will all be 
able to wake up when a new contact is created. The contact can be created 
asynchronously by another user on another machine on some LDAP server far 
away on a network that is broken half of the time, for example. So even the 
underlying Evolution / LDAP / KAddressBook libraries might not know.

Furthermore, keeping a list all contacts in memory can have a high cost in 
memory usage.

> 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.

Is that such a problem if the driver loops over an older version of the list?

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

Yeah, yeah. That was just an example.

> 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.

Well, most address books are expected to deliver names and telephone 
numbers ,-). But if you don't want to code hooks that return NULL all the 
time for properties that do not exist (which I can understand), there's an 
easy and clean variant:

class EkigaContact
{
	public:
		enum property { name, telephone, street, ... };

		virtual bool hasProperty(property p) const = 0;
		gchar *value(property p) const = 0;
};

So
	contact->value(street)
returns the street address and if
	contact->hasProperty(street)
is true.

> As a last comment, I will repoint the two arguments I have to prefer a
> GObject solution to a C++ solution :

Well, that's the kind of debate that can typically end up in a religious 
war ;-), but:
1) why reinvent the wheel? C++ has mechanisms for object programming, it's 
rather strange to reimplement them in C;
2) such choices tie Ekiga more deeply into GNOME libraries (okay, it's a GNOME 
project. But...)

> 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).

GBUS is indeed a nice invention ;-).


-- 
Éric