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

[Julien Puydt <jpuydt free fr>]

Jan Schampera a écrit :
> I'm currently coding a bit on a GmCallHandler object, some information
> and questions follow:
>
> Motivation
> ----------
> - central point to request call handling

Yes.

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

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.

> 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

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
>      signalling?

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.

Snark