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

[Éric Bischoff <ebischoff nerim net>]

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

What makes you think that they get "refreshed" at some point?

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

Promise, I will look someday what a "XMPP roster" is ;-).

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

Then you must some kind of evolved caching mechanism in your driver. That's 
sounds overcomplicated and hard to code to me. If you simply loop through the 
contacts, you can just get the information you need and display it.

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

If you convinced me of one thing, it's that I need to look at the definition 
of these SNMP toasters ;-).

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

Indeed! Excepted that you are just using the possibilities of the programming 
language, not of some library.

At this point, I must do some clarification:

I am a newcomer to Ekiga and perfectly aware of the fact that I might ignore a 
lot of things about the past and the possible future of this software. I am a 
complete ignorant of GNOME and its libraries. I do not know anything about 
the multithreading problems that Julien has to deal with. I am not here to 
slow down Julien, nor to get my views adopted. I will be more than happy to 
adapt my code to *any* API that Julien will bring up. And to shut my big 
mouth up if anyone ask me to ;-).

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

Okay, to me who comes from the KDE world, it's the same thing, it starts with 
"g" ;-).

> > GBUS is indeed a nice invention ;-).
>
> DBUS, not GBUS.

Yes, sorry for the many typos... :-/

-- 
Éric