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

[Julien PUYDT <jpuydt free fr>]

�ic Bischoff a �it :
> Le Mercredi 7 Juin 2006 17:57, Julien PUYDT a �it :
> > 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.

Well, for those what I propose still works :
- they get a list of contacts (and emit the "contact-added" signal for 
each) ;
- when they are refreshed, they remove all their contacts, and get the 
new list of contacts.

And what I propose works also for XMPP rosters, which are dynamically 
updated.

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

Indeed, some books shouldn't treat "get the list of contacts" 
litterally. That is why they shouldn't be too stupid :-)

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

To do what ? It is not a problem if the list of users on ekiga.net isn't 
updated live. But it certainly is if your XMPP roster isn't !

> > 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;
> };

Eh... this looks like GObject properties!

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

glib/gobject isn't gnome. It isn't even graphical.

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

DBUS, not GBUS.

Snark