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

[Thomas McGuire]

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

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

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

Does the connect() fail? What is the value of b?
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.

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

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

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

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/20100509/7a03ed6a/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/