[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:       "Aaron J. Seigo" <aseigo () mountlinux ! com>
Date:       2001-04-26 17:07:53
[Download RAW message or body]

Hi..

> How are you going to handle things like the fact that KMail supports
> features that kcmemail does not, like multiple incoming accounts. This will
> only continue with time for instance now we have identity based pgp user
> identities.

the easy answer is that i'm extending kcmemail to support things like 
multiple incoming accounts. 

> I'm not sure what kcmemail is intended to configure, I get the feeling that
> integration with KMail was something that was never really though about.

not specifically KMail, no. its mission seems to be to provide desktop-wide 
email settings. it is deffinitely lacking in some areas and i'm attempting to 
rectify that. from the header file in kio/emailsettings.h:

/**
  * This is just a small class to facilitate accessing e-mail settings in
  * a sane way, and allowing any program to manage multiple e-mail
  * profiles effortlessly
  *
  * @author Alex Zepeda jazepeda@pacbell.net
  **/

i think its partway there, but needs extending. it started out being 
something to support the ioslaves, but i think that to be complete it also 
needs information for the applications that use the ioslaves.

the question is: what settings should be set as generic desktop wide email 
settings and which are application specific? for instance, wether or not to 
send email immediately or to queue it (if appropriate in the circumstance) 
seems to me to be the sort of setting one would like to set across all email 
usage on the desktop. on the other hand, which folder the incoming email from 
an account should go into is deffinitely application specific. i'm seperating 
the various config options into these two groups and geting kcmemail to 
support the non-application specific settings.

the point i'm at right now is i'm dealing with the actual config file 
kcmemail uses which is accessed by some things in kio and the ioslaves, so i 
have to be carefule not to break things =))

the reason i'm doing all this is because i think consolidating email settings 
in one place instead of having them scattered hither and thither makes more 
sense for the user and the applications that support email messaging.

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

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. 

-- 
Aaron Seigo
_______________________________________________
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]