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

[Julien PUYDT <jpuydt free fr>]

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

Presenting to the user is frontend. Interaction with the roster is 
backend. I want the organisation to allow the user to interact with the 
roster in ekiga, through dbus or through whatever other method we make 
available -- and everything to work sanely.

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

I would like to have some intermediary layer which will push all of this 
into the glib mainloop, and take care of unthreading things, so 
everything built upon that layer won't have to do any locking.

There is a need for threading when you have audio/video streams. There 
isn't for simple actions.

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

This would indeed help a lot ! Unfortunately, I'm not sure anybody is 
working on this... and I haven't the skills to.

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

You cannot do everything with signals, indeed. And I don't want to put 
glib in opal, but wrap opal with some glib code :-)

Snark