[Kde-pim] close the Bug 77862: kio_imap processes

Sun Oct 31 17:16:01 GMT 2010

Short: I propose to close the bug 77862 because it can't be solved.

Long:
Bevor we can go on with the bug 77862, we have to define
the usecase(s) that are important for it. I see today two usecases.                                                                                    

1. As the bug was written, the user had a LAN-connection to use kmail.                                                                              
   After some works with it, he changes self the  ethernet-connection. This
   could have happened a few times a day. This happens at times without
   network activity.                                                                                                        
   This is the usercase I worked on and proposed two patches. The first one:
   May 2010, the second July 2010.                                                                                               

2. Now (2010), we have something new, as people use WLAN at airports, where
   the signal quality and strongness are not always the same. The signal
   changes, and with this the connectivity, much more often, without any
   action from the user.                                                                                                                                    

At the usercase 1, as described above, kmail has time to deal with                                                                             
the problem. With the first patch I proposed, we have to wait about one                                                                              
minute untill the signal from Solid::Networking::Status is coming. It is                                                                             
OK, because the user makes the change itself.
With the second patch, I propose to check the connectivity each time before                                                                          
(and after) the use of the socket. It is every time early enought to take a 
decision.

At the usercase 2, kmail has to deal with changes it don't know when
there occurs. With a check before the use of waitForRead, it might be already
too early. The change might occurs just after the check, just before the
use of the socket. The only chance we have, is that the kernel detects the
situation and gives back an error. 
In this situation I propose the use of a shorter timeout. About 20 seconds
might be a good value. If the WLAN signal is coming back, no trouble, if not
the user havn't have to wait too long.

This is the only thing we can do with IPv4. It is a only workaround and could 
never be better. My two proposals don't solve the bug. They are only 
workarounds for it.

The one who want to read a little bit more about this, should have a look to 
the RFC 3344: IP Mobility Support for IPv4. Introduction on page 3.
   http://www.ietf.org/rfc/rfc3344.txt

Let us examine the other protocols used by kmail: POP3 and SMTP.
The times they use the connections are short enough, so untill today, no user
had such a problem with them.

I think, this is NOT a imap-bug, this is NOT a kmail-bug. This is a 
networking-problem we can't solve with IPv4.

Let me now ask a provocative question?
What is the really necessary, **not to close** the connection after the 
transfer is done?
Why does kmail send a imap-NOOP each minute, even if the "check-interval" is
set to zero?
-- 
guy
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/