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

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

- central point to request call handling


- flexible adding/removing handlers: they don't need to be hardwired
  into the endpoint

Yes : think plugins.

- general information distribution due to signals

Not always : there are case where we'll want to prioritize matters.

First, a term used below:
  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

Will we have an "outgoing" list ?

  - calls all handlers one-by-one with a copy (!) of CALLINFOBLOCK

Sounds bad.

  - 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

Uh... but you sent a copy... so you don't get the result back.

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

I was not sure I understand why we care about the handling reason yesterday, but if the history is implemented by watching signals, then it's interesting indeed.

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

In fact, what about :
- when a new call arises, we run through the list of naysayers (blacklisting, DnD, autoforwarding, etc...) ;
- if no naysayers said to stop, then we go the signalling route ;
- if at least one said no, we just refuse the call.

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

The DBUS component will just listen for signals, and push them through DBUS without our caring. In fact, it should come as plugin, and we don't care about it at all.

(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

The handler tells the endpoint. The idea being that the endpoint lives in threads-land, while the signalling just happens in the main thread (no more problem with async replies in xlib...)

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

After the signalling, anyone could accept/refuse the call.


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