Re: [GnomeMeeting-devel-list] Refactoring the addressbook code
- From: Damien Sandras <dsandras seconix com>
- To: GnomeMeeting development mailing list <gnomemeeting-devel-list gnome org>
- Subject: Re: [GnomeMeeting-devel-list] Refactoring the addressbook code
- Date: Mon, 27 Mar 2006 23:24:14 +0200
Le lundi 27 mars 2006 à 23:18 +0200, Jose Carlos Garcia Sogo a écrit :
> El lun, 27-03-2006 a las 22:41 +0200, Damien Sandras escribió:
> > >
> > > 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.
> You have the same in Gloox. When you connect to the server you will get
> a roster in a RosterListener object that will handle roster callbacks.
> This is clearly a backend, that perhaps can be mapped to a more generic
> backend for dbus or other purposes.
> > 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.
> Yes, I see that, but I still think that we should define some general
> backend functions that can be called by SIP/SIMPLE or Jabber endpoints,
> and which call both gtk and dbus functions.
I agree with that, but Julien has another view (that I like, but don't
think easily feasible enough).
_ Damien Sandras
//\ Ekiga Softphone: http://www.ekiga.org/
v_/_ FOSDEM 2006 : http://www.fosdem.org/
SIP Phone : sip:dsandras ekiga net
sip:600000 ekiga net
] [Thread Prev