[Ekiga-devel-list] [ERFC] (Ekiga RFC heh) central point to manage calls

[Jan Schampera <jan schampera web de>]

Devs,

I'm currently coding a bit on a GmCallHandler object, some information
and questions follow:

Motivation
----------
- central point to request call handling
- flexible adding/removing handlers: they don't need to be hardwired
  into the endpoint
- general information distribution due to signals


First, a term used below:
-------------------------
CALLINFOBLOCK
  A struct containing all useful information about a call, such as the
  given token, the endpoint addresses, the current status, ...


Basic flow:
-----------
- endpoint receives an incoming call:
  - prepares CALLINFOBLOCK
  - requests call handling by GmCallHandler
- GmCallHandler:
  - fires a signal with CALLINFOBLOCK as data (1)
  - selects the "incoming" list where handlers are stored
  - calls all handlers one-by-one with a copy (!) of CALLINFOBLOCK
  - when a handler decides to handle a call it
    - changes (his copy of) CALLINFOBLOCK by putting the handling
      reason in
    - returns TRUE
  - when one handler returns TRUE:
    - the list is not continued
    - the current copy of the CALLINFOBLOCK is checked for the details
  - when the list is done, there are two cases:
    - call was not handled --> fire signal with CALLINFOBLOCK with
      "unhandled" as data (2)
    - call was handled --> fire signal with CALLINFOBLOCK with the
      handling reason as data (2)
AWAITED PROBLEMS
 - none so far


The reasons for the signalling:
-------------------------------
(1) Inform all interested components about the call event
 - this is NOT meant to do the actual handling, just informational
 - let the DBUS component signal stuff
 - let something write something into some log
 - ...
 AWAITED PROBLEMS
 - why should the whole Ekiga code world be informed about an incoming
   call and just 5ms later be informed that the call was rejected by a
   blacklist

(2) Inform all interested components about how the story ended
 - again, let the DBUS component signal around
 - let the ringer stop ringing
 - let the icon show "connected" or whatever status fits
 - let the imaginary logger from (1) log something
 - ...
 AWAITED PROBLEMS
 - none so far


Questions:
----------
(R1) is it better to let the handler e.g. accept a call by telling the
     endpoint or is it better to let the endpoint listen to the final
     signalling?

(R2) for the DBUS component, to answer a call, in (R1) a handler-sided
     accept sounds better


Regards,
Jan

-- 
Der Mensch, der bereit ist, seine Freiheit aufzugeben, um
Sicherheit zu gewinnen, wird beides verlieren.
- Benjamin Franklin