From kmail-devel Thu Apr 26 17:07:53 2001 From: "Aaron J. Seigo" Date: Thu, 26 Apr 2001 17:07:53 +0000 To: kmail-devel Subject: Re: Bug#24532: integration of kmail with knode X-MARC-Message: https://marc.info/?l=kmail-devel&m=98830611711149 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