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

[Thomas McGuire]

Hi,

On Saturday 15 May 2010 12:14:27 Guy Maurel wrote:
> Thanks for writting, I know you have much more trouble to day with the
> time delay...
> 
> On Friday 14 May 2010 22:53:53 Thomas McGuire wrote:
> > Hi,
> > 
> > Oh, I see, this explains why closing the connection does not work, as the
> > IO
> 
> NO! It is NOT the explanation!
> 
> > slave probably is waiting somewhere, so the commands get not dispatched.
> 
> 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() 
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)

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

> > > **WHY** do we need this "if (getState() == ISTATE_NO)" ?
> > 
> > The documentation says ISTATE_NO stands for "Not connected", so if it is
> > not connected, we don't need to disconnect. Are you sure the slave is
> > actually connected at that point?
> 
> Yes. One have got data from the server, short before, and I found nobody
> who makes a disconnect.
> Many of the call to getState() in the imap4.cpp are preceded by a setting
> of the state to ISTATE_CONNECT, E.g. line 683:
>   setState(ISTATE_CONNECT);
> It looks like to make sure it is possible to go through.
> And, there is NO possibility to send anything (from kmail) to use the
> setSate. The only one is from imap4.cpp itself. There I ask again: Why do
> we need this "if" ?

I am not quite sure how the state handling works. If the state is ISTATE_NO 
when the slave is still connected, that would be a bug.

> Let me introduce another point.
> There is not any "button" in kmail for the user, if he/she wants to
> disconnect from the server. And if we add such a "button", we have to
> resolve the same problem: why do we need this "if (getState() ==
> ISTATE_NO)" ?

Well the if statement says: If there is no connection, then don't bother to 
disconnect. I think it makes kinda sense.
Yes, there is no button to disconnect in KMail 1, but we can't add one either, 
since it is in feature-freeze.

Regards,
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20100515/a3e0f1de/attachment.sig>
-------------- next part --------------
_______________________________________________
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/