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

[Damien Sandras <dsandras seconix com>]

Le lundi 27 mars 2006 à 22:28 +0200, Julien PUYDT a écrit :
> Jan Schampera a écrit :
> > I thought about the following API (not implemented, draft!, partly
> > pseudocode, symbolnames should explain themselves):
> > 
> > 
> > GMRoster* gmroster_new (void);
> > 
> > void gmroster_add_entry (GMRoster*, GMContact*);
> > void gmroster_del_entry (GMRoster*, GMContact*);
> > void gmroster_modify_entry (GMRoster*, GMContact*);
> 
> This is backend.
> > void gmroster_set_icon (GMRoster*, enum state_type, GdkPixbuf*);
> > void gmroster_set_show_offlines (GMRoster*, gboolean);
> > gboolean gmroster_get_show_offlines (GMRoster*);
> > void gmroster_set_show_in_multiple_groups (GMRoster*, gboolean);
> > gboolean gmroster_get_show_in_multiple_groups (GMRoster*);
> > void gmroster_set_unknown_group_name (GMRoster*, gchar*);
> > void gmroster_set_show_groupless_contacts (GMRoster*, gboolean);
> > gboolean gmroster_get_show_groupless_contacts (GMRoster*);
> 
> This is frontend.
> 
> > - a contact is identified by its uid AND its name field
> 
> Hmmmm... it should only be the uid. You could want to rename a contact! 
> This is backend.
> 
> > - the widget holds a private copy of each contact
> 
> This is frontend.
> 
> > - the widget self-organizes which groups to show/not show by
> >   scanning the proper the GMContact member
> 
> This is frontend.
> 
> > - the GMContact "state" member is used to determinate offline, online
> >   and away status
> 
> Ok. Does SIP/SIMPLE allow to attach a string to the status ? (Like "I'm 
> gone for dinner -- be back near 20".) This is backend.
> 
> > - gmroster_modify_entry() only scans the "state" member of the
> >   contact (to update the presence)
> 
> What if I want to rename sip:500 ekiga net from the "500" I set at first 
> to the saner "Miroir de test" ? This is backend.
> 
> > - the *_show_in_multiple_groups() will control, if a contact that
> >   belongs to more then one group is shown in its first group found or
> >   in all groups found (discussion?)
> 
> I'm not sure I understand this one ; but it seems frontend.
> 
> > - the *_show_groupless_contacts() control weather a contact without a
> >   group entry is shown in a group named by
> >   gmroster_set_unknown_group_name(), or not shown at all
> 
> In my little pet project, I have a group named "Unsorted" exactly for 
> that. This is frontend.
> 
> I really want a strict backend-frontend separation.

Then define what you call a backend and a frontend, because your view
seems to be DBUS-biased for now :-)

Let's start the discussion we had 3 years ago again now.

Here is how I see things.
You will have an OpalSIPPresenceEndPoint, an OpalJabberPresenceEndPoint,
and any other endpoint for presence. Those endpoints represent, from my
point of view, the backend. 

In OPAL, you have C++ objects (backend). This C++ objects have methods,
to take an action, and callbacks, which reacts to actions.

In Ekiga, you have GTK+ functions (frontend). All functions defined by
Jan are GTK+ functions. They do not manipulate the C++ objects, they
only manipulate the GUI part of Ekiga.

We can not have generic functions that will modify :
- the frontend (GTK+)
- the backend (OPAL EndPoint)
We have to keep both separate.

Why? Because GTK+ SUCKS. GTK+ is not thread-safe, and is playing bad
games with multi-threaded programs.

Imagine you have a generic function that manipulates the front-end and
the back-end, that would lead to situations like this:

some_generic_function () 
{
gdk_lock_take;
update_ui;
gdk_lock_release;

lock_endpoint;
update_endpoint;
lock_endpoint_release;
}

Just at the same time, an OPAL callback is called, the lock_endpoint is
taken. In the callback, you want to modify the UI, so you do :

lock_endpoint taken;
callback ()
{
gdk_lock_take;
update_ui;
gdk_lock_release;
}

That leads to a deadlock....

There are 2 solutions to that problem:
1) Fix GTK+ so that it can enters the nineties as a modern thread-safe
toolkit... (What? we are in 2006, shit...)
2) Work by a system of signals. That is not really possible, you can not
do everything with signals, and adding GLIB code into OPAL is not
something nice to do.
- 


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