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

Jan Schampera a �it :
First rudimentary working code snips. Signals are missing, the rest
more or less works.

Ok, I already made some comments on irc, let me just remind here the two main points : - the call handler is supposed to handle calls, but most of its api is to handle call handlers ;
- it seems possible to both accept and reject a call!

Here is an idea I had this evening -- I don't know yet how good it fares.

The basic point is that with GObjects, signal handlers can return a result -- and those results are passed to an accumulator, which will determine what to do with it.

So let's say a call has the following states :
- incoming
- outgoing
- ringing
- accepted
- rejected
- forwarded
- stopped
and the endpoint emits signals about each of those.

Let's make the incoming signal handlers return an action to perform, like :
- accept ;
- reject (+ reason) ;
- forward (+ url).

Once every handler of this signal has replied what it thinks about it :
- if all want to accept, accept the call ;
- if at least one wants to reject, reject ;
- if several want to forward to different hosts... then I don't know.

That way the call history would just watch all those signals, when an incoming call arrives, it notes down which time it is, and when it is rejected/forwarded/whatever, it knows about it too.

The ringer would only be interested in watching the ringing and stopped signals (to begin/stop the ring), just like the popup menu.

Does that sound sane ?


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