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

[Jan Schampera <jan schampera web de>]

On Wed, 21 Mar 2007 10:55:45 +0100
Julien Puydt <jpuydt free fr> wrote:

> > - flexible adding/removing handlers: they don't need to be hardwired
> >   into the endpoint
> 
> Yes : think plugins.

Exactly.

> >   - selects the "incoming" list where handlers are stored
> 
> Will we have an "outgoing" list ?

Yes. Think of administrative restrictions in system config. One of
GConf's marketing blabla is that the admin can set such things. If it's
used or not doesn't make a difference, it's just another GSList*. The
base code is the very same.

> >   - calls all handlers one-by-one with a copy (!) of CALLINFOBLOCK
> 
> Sounds bad.

Why? A copy ensures that the handler can't destroy relevant parts of
the CALLINFOBLOCK
> >     - 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.

I send a copy, means, I dup() the struct and send a pointer to the
duplicate. After the handler returned (TRUE) I evaluate the copy, make
my decisions, free() it.

> > [...signalling...]
>
> 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.

Yes.

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

Well, think again of the basic case of logging. Maybe an information "a
call comes in" is useful at the beginning. Maybe split into two
signals, SIG_INFO, SIG_PLEASE_HANDLE or so.

> > (2) Inform all interested components about how the story ended
> >  - again, let the DBUS component signal around
>
> 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.

Yes.

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

ACK, good argument.


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

See also the idea for two different signals (though useless, as the
object can't control it, of course).


Best regards,
Jan


-- 
0xFEEDFACEDEADBEEF!