[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: Bug#24532: integration of kmail with knode
From:       Don Sanders <sanders () kde ! org>
Date:       2001-04-27 12:25:45
[Download RAW message or body]

On Friday 27 April 2001 03:01, Neil Stevens wrote:
> On Wednesday 25 April 2001 07:49 pm, Don Sanders wrote:
>  > If you (or anyone else) would like to contribute to KMail adding smtp
>  > auth support to KMail would be a nice way to start. I guess that
>  > requires changing the KMail configuration dialog to add an smtp
>  > authentication checkbox, and kmsender.* to implement a third sendProc
>  > based on the smtp ioslave. Then this sendProc should be used when auth
>  > smtp is selected.
>
> You know, I didn't have a chance to do the GUI, but that's exactly what
> I did, that you reverted. :-)

I reverted the commit not because of problems with the code but because the 
code was unfinished and it didn't look like anyone had time to finish it.

We can't just switch KMail over to using the smtp slave before the smtp slave 
is trusted. It took many months before we changed from the blocking pop3 
system to the pop3 slave.  A gui option to provide smtp authentication, and 
then only using the smtp slave when that option is selected is a nice way to 
make the transition from smtp.cpp to using the smtp slave. 

On Thursday 26 April 2001 19:07, Aaron J. Seigo wrote:
> i think Neil already did this..
>
> is this the best way though? why keep kmail's own smtp methods when
> kio_smtp exists? why require kmail to even know about special features such
> as smtp auth if the ioslave can just pull these options out of kcmemail and
> have it occur whenever its used to send email (which is actually how it
> works w/kio_smtp as i understand it). it seems that hacking in support for
> smtp auth to kmail itself seems contrary to the ioslave concept and that
> kmail ought to simply use the ioslave and the slave should know what it
> needs to do (e.g. send w/authentication) based on settings the user
> provides in kcmemail.

When the smtp slave proves it stuff then we can drop the smtp.cpp code 
completely. Indeed it appears that smtp.cpp has problems with dns lookup 
sometimes so there are definitely benefits to dropping it.

One final point I don't think kcmemail should be relevant to the issue of 
using the smtp slave. I hope the smtp slave doesn't rely on kcmemail, and I 
think the kcmemail issue, should be dealt with separately from the smpt slave 
issue. 

If the smtp slave needs information to perform the authentication then that 
information should be passed as arguments to the slave.

BFN,
Don.

BTW this new select text in the reader window that you want to reply to 
feature is very cool!
_______________________________________________
Kmail Developers mailing list
Kmail@master.kde.org
http://master.kde.org/mailman/listinfo/kmail

[prev in list] [next in list] [prev in thread] [next in thread]