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

[Damien Sandras <dsandras seconix com>]

Hi,


The current behavior is part of a discussion that we had together 2
years ago. I can understand you changed your mind in-between, however I
do not think we can afford rewriting things that work for 2.2 or 3.00.

With me being nearly alone coding on OPAL, we do not have the time to do
complex changes on such things that are not user-visible.

So if you tell me it will take you 2 evenings, then I will tell you: do
it.

If you tell me that it will take you 1 month, then I vote against it.

If you are using a change -> signal -> modify approach, you will quickly
see in the gmconf backend that the easiest way to do things is to
rebuild entirely the address book for each change. That is not an
option. So you will have to know in your GMConf callbacks what contact
has been modified/deleted/added and modify only this one in the GUI.


Le vendredi 24 mars 2006 à 21:49 +0100, Julien PUYDT a écrit :
> Hi,
> 
> I am not satisfied with the addressbook code.
> 
> The main problem is that the separation backend-frontend isn't good enough :
> - it's not the addition of an addressbook or contact which triggers
> showing it in the window... both actions are done sequentially.
> Typically it means that in the future, the dbus component would have to
> both create things in the backend, and cope with the ui (!).
> - I had a bug that when I removed all local addressbooks, adding one
> again was broken, because there were no more addressbooks groups. The
> fix was easy : create what's needed ! But... if adding an addressbook
> now works (no more warnings, it _is_ there), it isn't shown in the ui 
> before a restart !
> 
> I would really like to see parts of it rewritten for 2.2, with the
> following hard constraints :
> 1) no loss of feature ;
> 2) the eds/avahi/whatever code must move as little as possible (so their
> respective contributors could still recognize their code and work on it);
> 3) backend and frontend must be really separated, so that another
> frontend (the dbus component) could appear and work without requiring to
> further modify things.
> 
> Notice that the point (2) means that we will respect whatever format was
> used to store things in the configuration, and hence we won't break
> user's configuration -- which is important for a 2.x release.
> 
> I'm not sure of what to do yet, but I think it should be possible to do
> interesting things by just rewriting :
> - lib/gmcontacts/gmcontacts.cpp ;
> - lib/gmcontacts/gmcontacts.h ;
> - src/gui/addressbook.cpp.
> 
> The reason is that going from frontend to backend, things are layered
> like this (as far as I can tell) :
> src/gui/addressbook.cpp
>    lib/gmcontact/gmcontacts.cpp
>      lib/gmcontact/gmcontacts-remote.cpp
>         lib/gmcontact/gmcontacts-avahi.cpp
>         lib/gmcontact/gmcontacts-ldap.cpp
>      lib/gmcontact/gmcontacts-eds.cpp
>      lib/gmcontact/gmcontacts-gmconf.cpp
> 
> Does that look sane ?
> 
> Snark
> _______________________________________________
> Gnomemeeting-devel-list mailing list
> Gnomemeeting-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnomemeeting-devel-list
-- 
 _      Damien Sandras
(o-     
//\     Ekiga Softphone: http://www.ekiga.org/
v_/_    FOSDEM 2006    : http://www.fosdem.org/
        SIP Phone      : sip:dsandras ekiga net
                         sip:600000 ekiga net