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

[kde]

Hi again!

On Sun, 9 May 2010 19:24:05 +0200, Thomas McGuire <mcguire at kde.org> wrote:
> Hi,
> 
> you seem to have a pretty good understanding on how the KIO slave 
> communication works, by now :)
> 
> On Sunday 09 May 2010 11:41:09 Guy Maurel wrote:
>> On Friday 07 May 2010 21:18:02 Thomas McGuire wrote:
>> > Right now, stopNetworkJobs() doesn't actually change the network
>> > status.
>> > I think simply calling AccountManager::cancelMailCheck() might already
>> > be enough for this.  Can you check if that works?
>> 
>> I try (again) the proposal:
>>   the_acctMgr->cancelMailCheck();
>> 
>> but it is not enough. We get:
>>   kmail(2169)/kio (Scheduler) KIO::SchedulerPrivate::disconnectSlave:
>> _disconnectSlave(  KIO::Slave(0x1577d70) )
>> 
>> The slave is "only" disconnected. The kio_imap process is still leaving.
> 
> Disconnecting and then re-connecting should work, right? I don't see a
> problem 
the "reconnecting" works...

> that the KIO slaves are still running when they are not connected. If
there
> 
> are problems with the IP address, re-connecting should solve that.
**THIS** is the problem is the IP-address changes. 
This a problem of IP-v4. It is well known. So as the IP-v6 got designed,
the roaming-mechanism is introduced to solve this situation, without
having a loose of the connection(s) with server(s).
With IP-v4, one have to kill all part of the connection!

> 
>> ===========
>> 
>> As the IP-topology is changing, the kio_imap-slave *cannot* be use
>> anymore,
>> because it is only valid with the old IP-address. We must kill this
>> process, so kmail have to create a new one. Allready the description
from
>> Mike Culbertson 2004-03-17 tell us that: "... have to manually kill the
>> kio_imap4 processes"
>> The next confirmations are:
>> Comment #7 From Petr Burian: "... quick solution to solve this is to
kill
>> all kio_imap processes" Comment #13 From Michael Kreitzer: "... kio_imap
>> processes are killed" Comment #16 From Apollon Oikonomopoulos: "... I
>> have
>> to kill all kio_imap4 instances manually" and many more.
> 
> Killing the process is just a workaround, not the real solution.
see above. It is more that a workaround. How to do that? Let us try
to find the best way...

> 
>> I experience a bit and found three possible ways to do this.
>> 
>> The first solution:
>> ===========
>> The must pretty one, is that the kio_imap-process kills itself.
Something
>> like that. First, the class IMAP4Protocol needs to derived also from
>> QOject.
>> kdepimlibs/kioslave/imap4/imap4.cpp at
>>   IMAP4Protocol::IMAP4Protocol (const QByteArray & pool,...
>>   bool b;
>>   kDebug(7116) <<"IMAP4: connect it";
>>   b= connect( Solid::Networking::notifier(), SIGNAL( statusChanged(
>> Solid::Networking::Status ) ), this, SLOT( slotNetworkStatusHasChanged(
>> Solid::Networking::Status ) ) ); kDebug(7116) <<"IMAP4: connect it is="
>> <<
>> b;
>> and the slot should call the "IMAP4Protocol::closeConnection()"
>> *BUT* it doesn't work. The slot doesn't get the signal. I don't
>> anderstand
>> why not
> 
> Not sure about this solution. The solution has the big disadvantage that
> I'm 
> not sure if KMail is aware that the slave has disconnected, it will
> probably 
> mean that the user will see an error message, or that strange bugs happen

> because the slave is disconnected while KMail is doing a mail check. So
I'd
> 
> prefer to go with the second solution.
NO. The Kmail got inform about the killed slave and changes itself in order
to work on at the next call...

> 
> Does the connect() fail? What is the value of b?
It is waht I don't anderstand. The connect returns "true"...

> Have you look at the debugging output? It should say the reason why the 
> connect fails. 
> If the connect does work, check with a debugger what is going wrong.
I still cannot found anything wrong. I look ahead...

> 
>> The second solution:
>> =============
>> It could be to send the command CMD_DISCONNECT, defined by
>> kdelibs/kio/kio/global.h. The command is received at
>> kdelibs/kio/kio/slavebase.cpp:940
>>   void SlaveBase::dispatch( int command, const QByteArray &data )
>> and makes the right call at line 963
>>     case CMD_DISCONNECT: {
>>         closeConnection( );
>> *BUT* this command is not used (not implemented) by the imap part of
>> kmail.
> 
> I like this solution most.
I also, but some part are misssing. I try to explain better what I found:
> 
> What do you mean that it is not implemented? On the slave side, it is 
> implemented, see IMAP4Protocol::closeConnection() (closeConnection() is
> called 
> by SlaveBase::dispatch() for CMD_DISCONNECT).
The kio_imap is well written, but no command CMD_DISCONNECT is send to it.
We have to take care of the signification of "disconnect".
The meaning is different between "kmail" and "kio_imap"...

> Or do you mean that KMail doesn't send CMD_DISCONNECT? Looks like that is
> just 
> a matter of calling KIO::Scheduler::disconnectSlave(). disconnectSlave()
is
> 
> actually called from KMAcctImap::killAllJobs(), which itself is called
from
> 
> KMAcctImap::cancelMailCheck(). Have you tried finding out why this
doesn't 
> work? You said above that cancelMailCheck() doesn't work, even though it
> seems 
> to send CMD_DISCONNECT to the slave internally.
NO, no CMD_DISCONNECT is send.
I put a break-point whithin gdb at the dispatch of kio_imap, and got not
any command to disconnect...

> 
>> The third solution:
>> ===========
>> This is the one I propose today. This could be used immediately.
> 
>> The "system"-command is allready used by
>> kmfoldermbox.cpp (12 times)
> 
> Ok, true. However, kmfoldermbox is not the best example of nice and
> portable 
> code :)
> 
>> I am not sure! Not using the KIO slaves is only one part of the
solution.
>> The new solution should also take care of the sifgnal emmited for
>> Solid::Networking...
> 
> I think Akonadi does that internally somewhere, but I'm not sure. This
> would 
> need testing/confirmation.
It could be very important to check this, may be at some other place (POP3)
to be sure, no to get a similar problem...

> 
> Regards,
> Thomas
Thanks for the discussion.
guy
-- 
guy maurel
_______________________________________________
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/