Re: [GnomeMeeting-devel-list] Refactoring the addressbook code
- From: Julien PUYDT <jpuydt free fr>
- To: GnomeMeeting development mailing list <gnomemeeting-devel-list gnome org>
- Subject: Re: [GnomeMeeting-devel-list] Refactoring the addressbook code
- Date: Tue, 28 Mar 2006 11:14:21 +0200
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 :-)
] [Thread Prev