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 _______________________________________________ Ekiga-devel-list mailing list Ekiga-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-devel-list