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

[Guy Maurel]

Hi !

On Thursday 20 May 2010 19:27:33 Thomas McGuire wrote:
> Hi,
> 
> On Tuesday 18 May 2010 19:28:18 Guy Maurel wrote:
> > > Please try out if setting a timeout works. You can either use something
> > > else than responseTimeout() whan calling waitForResponse(), or use     
> > > setMetaData to set a lower response timeout (with the "ResponseTimeout"
> > > key). The metadata is internally used by SlaveBase::responseTimeout(). 
> >                                                                          
> > it doesn't work on this way because the                                  
> >    void SlaveBase::setMetaData(const QString &key, const QString &value) 
> > use the                                                                  
> >     mOutgoingMetaData.insert(key, value);                                
> >                                                                          
> > and the                                                                  
> >    QString SlaveBase::metaData(const QString &key) const                 
> > use another variable                                                     
> >    if (mIncomingMetaData.contains(key))                                  
> >                                                                          
> > or there is some method to copy the data??                               
> 
> Oh, I see, there are two different kinds of metadata, didn't know that.
> I think the incoming metadata, which includes the response timeout, can only 
> be set from the application.                                                 
> Maybe try setting this in ImapAccountBase::slaveConfig()? This method creates 
> the metadata that is sent to the slave, and I think it will be available there 
> as mIncomingMetaData.  
this works very fine...
 
> There are two different kind of timeouts: The first one is the timeout for 
> waiting when reading or waiting to read from a socket. That is what I talked 
> about earlier.                                                               
> The second timeout is the timeout until a KIO slave process gets killed. When 
> KIO slave processes are not used anymore, they are kept around for some time 
this is right.
this is the one we have to kill because we cannot use it anymore.

> I think the re-using the same slave after suspend/wakeup is no problem, and 
> therefore the slave reuse timeout can stay high.
> The only thing we need to make sure is that the connection gets disconnected 
> and reconnects again on wakeup. As far as I can see in the code, the slave 
> will automatically close the connection if the response timeout is triggered, 
> right?
more!
We have two cases.
1. the ethernet connection is coming again with the same IP-address
2. we get another connection with an new address.

The problem is, we cannot (so far I can see) get information about our own
IP-address. It would be very easy to take a decision.

In both cases, we have to make sure, that kmail is able to connect again.
The (soft) way we are trying togother today is not sure enough. I have to
investigate why: a new kio_imap is created, but the connection: app->job->slave
doesn't work.
I will check this next week.

bye
-- 
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/