[Kde-pim] Proposal for a solution for bug 77862

[Guy Maurel]

Hi!

an anwser to the first part...
On Saturday 15 May 2010 18:56:46 Thomas McGuire wrote:
> Hi,

> > NO! The slave is waiting... but it never got anything, because the command
> > bevor was not sent. It was not sent because the IP has changed!
> 
> What I meant: As soon as the connection gets stuck (for example because the IP 
> address did change), the slave stays in one of the waitForReadyRead() 
or a loose of an IP-address...

> functions. That means the control flow never goes back to the dispatch loop, 
> so even if KMail sends CMD_DISCONNECT, that command is never dispatched (or 
> only dispatched after the default timeout, which is too long)
exact!
The problem is, we have not many time to do something. Even if the user don't
do anything, the kmail send at least after 60 seconds a CMD_SPECIAL-command.
This command do nothing but read the line and we have to wait...
> 
> > > However, all the waitForReadyRead have a timeout parameter. Is that
> > > timeout to high? We might just be enable to lower it.
> > 
> > The timeout value is set by default. To change it, look at the well written
> > comment https://bugs.kde.org/show_bug.cgi?id=77862#c48
> 
> Ok, so the question is: Can we change the timeout manually in the IMAP KIO 
> slave? Sounds that would solve the bug.
yes, we could!
But, what is the winn? We don't know what really happens (only timeout). We 
don't get information about the line with this way.

On Monday, 10 May I wrote about three solutions, and
  "The must pretty one, is that the kio_imap-process kills itself...
    BUT it doesn't work. The slot doesn't get the signal."
Could it be that slot doesn't get the signal because of the same reason as above?

your opinion now?
thanks
-- 
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/