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

[Julien Puydt <jpuydt free fr>]

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?

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

Snark