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

[Damien Sandras <dsandras seconix com>]

Le lundi 27 mars 2006 à 23:46 +0200, Jose Carlos Garcia Sogo a écrit :
> 
>   Then, I don't have very clear yet how Julien thinks things should be
> done. If he is interested in being able to map to dbus, he should agree
> with that intermediate generic layer.
> 

Jan proposed a set of functions that only modify the GUI, ie the
frontend.
Damien and Jose think implementing C++ classes that will manage the
backend, ie the backend. The backend has callbacks that will modify the
GUI.

------------

Let's take an example. The user wants to change its status to Away.


Here is how I think it should work so that we do not have problems with
mutexes:
- The user goes in the menu and chooses "Away". It triggers a GTK+
callback.
- The GTK+ callback does two things :
  1) It calls a function of the backend to set the user as Away on the
server.
  2) It calls a function of the frontend (one of those defined by Jan)
and updates the UI.

------------

Here is how Julien thinks it should work:
- The user goes in the menu and chooses "Away". It triggers a GTK+
callback.
- The GTK+ callback does one thing :
  1) It calls a unique function that updates both backend and both the
frontend.

So instead of presenting to the developer 2 functions, one to update the
UI, and one to update the backend, we present only one that is doing
both things.

------------

I think Julien is right. However, both backends are using locks. And
those locks are not necessarily taken in the same order. For example, in
a GTK+ callback, the GDK lock is taken when the callback is called. In
an Opal callback, some OPAL lock can be taken when the callback is
called. That means that in the GTK+ callback, you would have this order:
1) GDK lock, 2) Opal lock, while in an OPAL callback, you would have
this order : 1) Opal lock, 2) GDK lock .

The consequence is that you can have a deadlock.

For that reason, we have to keep UI modification and back-end
modification separate.

------------

Another way of doing things is the following.
- The user goes in the menu and chooses "Away". It triggers a GTK+
callback.
- The GTK+ callback does one thing :
  1) It calls a unique function that updates the backend.
- When the backend is updated, it also does one thing :
  1) It triggers a callback, that callback updates the GUI.

The problem is that if you take GLOOX as example, it doesn't necessarily
works this way. You probably have a function to change the state of the
registered user, and that doesn't trigger a callback when the state is
changed. So we can not follow that third approach.

The reason is that GTK+ is not thread-safe.

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