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

[Julien PUYDT <jpuydt free fr>]

�ic Bischoff a �it :
> Le Mercredi 7 Juin 2006 21:30, Julien PUYDT a �it :
> > > 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?

The user triggers the "refresh" action :-)

> > And what I propose works also for XMPP rosters, which are dynamically
> > updated.
>
> Promise, I will look someday what a "XMPP roster" is ;-).

Perhaps you know what a "jabber roster" is?
http://mailman.jabber.org/pipermail/jadmin/2005-June/021875.html

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

I don't think a trivial proxying counts as an "evolved caching 
mechanism" :-)

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

Who's toast ? ;-)

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

Can you add properties to the enum when inheriting ?

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

Yes, yes, no problem. I'm happy to have feedback :-)

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

glib, gobject & gtk+ already make ekiga run on win32.

> > > GBUS is indeed a nice invention ;-).
> > DBUS, not GBUS.
>
> Yes, sorry for the many typos... :-/

Eh... that one was pretty bad for someone who has something against 
g-letter words ;-)

Snark