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

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]