Re: [Ekiga-list] Ekiga contact presence

[Jim Diamond <Jim Diamond acadiau ca>]

On Fri, Jul 10, 2009 at 12:22 (+0200), Eugen Dedu wrote:

> Damien Sandras wrote:
>> Le vendredi 10 juillet 2009 à 12:13 +0200, Eugen Dedu a écrit :
>>> Mateusz Kaduk wrote:
>>>> Hi,

>>>> I am on Debian (sid) still using 3.2.1~git20090515. I would like to
>>>> know if this issue was fixed in upcomming 3.2.5.
>>>> The problem is with contact availability status it gets rarely updated if ever.

>>>> How does ekiga server determinate if user is still online? Are there
>>>> any ping-pong requests send ?
>>>> My girlfriend turns off ekiga, but I still see her online, when I come
>>>> back I try calling, after restarting ekiga this status is updated.

>>>> How long it takes to update user status in a normal working case ? Is
>>>> it a bug or just design ?
>>> If I remember correctly, when a person quits ekiga, there is no update 
>>> sent on the server.  However, the server (or the client) periodically  
>>> (15 min I think) sends info to remote party about the presence.  So,  
>>> when a person quits ekiga, it will take at most 15 min to update his  
>>> presence.

>>> Quitting ekiga does not send an update because people wanted that 
>>> ekiga finishes fast.  I still think that it is better that ekiga sends 
>>> an update and waits for the answer, even if it takes a 1-3 seconds.  
>>> The proper fix would be to hide that from the user, for ex. when the 
>>> user quits the GUI finishes, but not the program.


>> Like it was before, but users complained that it did not exit cleanly.
>> Users generally do not agree between themselves ;-)

> :o)

> The best solution is still to hide the GUI, don't you agree?

Speaking as a user who used to wonder if gnomemeeting was *ever* going
to go away (note I mean gnomemeeting, not ekiga), I was interested to
see the "1-3 seconds" comment.  I agree that having the gui vanish,
and possibly having the program fork() itself into the background (in
case someone started it from a shell and expects to see a new prompt
at some point) would be a Good Thing.

I used to assume that the reason for gnomemeeting taking forever was
because of some idle and tedious chit-chat with gconfd.  Certainly, I
waited way, way, way longer for gnomemeeting to finish than 1-3
seconds, and when I first compiled ekiga w/o gnome support, I was
pleased to see it quit more or less as soon as I asked it to quit.
While ekiga != gnomemeeting, I am wondering if some of the time to
finish is actually ekiga and gconfd having long talks about something.

Cheers.
				Jim