Re: [Ekiga-devel-list] [THREADNESS] H.323 endpoint

[Damien Sandras <dsandras seconix com>]

Le lundi 20 novembre 2006 à 21:04 +0100, Julien Puydt a écrit :
> Damien Sandras a écrit :
> > I don't see the need to do that now.
> 
> The intent is to fix http://bugzilla.gnome.org/show_bug.cgi?id=353533 , 
> which will make ekiga more robust by using threads only when strictly 
> necessary.
> 
> Ekiga is currently a crash-test dummy for its dependancies. And it's the 
> only one. That means that whenever any dependancy has a multi-threading 
> bug, ekiga and only ekiga crashes, which :
> (1) makes ekiga look bad ;
> (2) doesn't appear as that critical to said dependancy's developpers, 
> and hence doesn't prompt a swift and efficient answer.
> 
> Isn't http://bugzilla.gnome.org/show_bug.cgi?id=359655 enough to 
> convince you?
> 

Not really. Because :
1) Ekiga exists since 6 years now, and it is the first time we have such
a problem, just because Edgy was not tested
2) I'm not 100% convinced yet that the right fix is to hide bugs by
hiding threads
3) It is certainly not a priority for 3.00.

> > In the end, we will have introduced so many changes that we will not
> > have the time to finish, that 3.00 will be delayed for ever...
> 
> You're always optimistic ;-)
> 
> >> More ideas later, I'm hungry ;-)
> 
> Ok, here is an idea : the endpoint doesn't do anything more than emit a 
> signal to say there's a new call token in state CALLED.
> 
> We have a piece of code which reacts to such signals and shows the usual 
>   answer call window.
> 
> We have a piece of code which reacts to such signals by ringing.
> 
> We have a piece of code which reacts to such signals by either 
> auto-refusing (DND), auto-forwarding or forward-on-no-answer.
> 
> We have a piece of code which makes the information available as a 
> notification in the status icon.
> 
> We have a piece of code which marks us as busy on the local network (avahi).
> 
> We have a piece of code which marks us as busy on ekiga.net.
> 
> All of those pieces more generally react whenever the call token changes 
> state, so for example the window disappear when the user 
> refused/accepted by any mean, or the other end stopped the call.

I must be straightforward :
- We have an excellent piece of code from you waiting to be completed to
be integrated in 3.00
- There is an excellent piece of code lying in the queue for XVideo
support
- There is another excellent piece of code from Google SoC for IAX2
support
- SRTP support seems in good shape
- There is a WIN32 port to complete
- Ekiga.net needs an upgrade (software)
- Ekiga.net needs an upgrade (hardware)
- Presence support still needs to be committed
- We have dozens of bug reports to fix in Bugzilla (enhancements, bugs
in opal, bugs in pwlib, ...)
- The plugins systems from Craig is not ready for production use
- We have the druid to rewrite
- ...

All of this before 3.00, ie we have 2 months left (December, January, a
part of February).

So please do not start still another piece of code that we won't be able
to finish. Your help is required in all other places.


-- 
Damien Sandras

Ekiga Softphone : http://www.ekiga.org
NOVACOM                    : http://www.novacom.be
FOSDEM                      : http://www.fosdem.org
SIP Phone               : sip:dsandras ekiga net