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

List:       kmail-devel
Subject:    Re: kio_smtp and kmail identities
From:       "Aaron J. Seigo" <aseigo () mountlinux ! com>
Date:       2001-05-11 6:04:00
[Download RAW message or body]

Hi..

> Why can't the slave simply accept a common URL, like nearly all other
> slaves?

because it was originally designed to work off of "profiles" that details all 
the info, not raw hostnames/passwords/etc.. the creation/management of these 
profiles is done via a helper class and there is fairly trivial. this is how 
i would do it if i am going to duplicate the info in kmail and in the desktop 
settings, so it would be transparent to the user. however it still raises the 
issue of the user changing those settings directly in kcmemail and having 
them fall out of sync. blick.

> smtp://username:pass@host:port/
> and
> smtps://username:pass@host:port/
>
> should do the trick.

you haven't actually looked at kio_smtp have you? *grin* to allow sending of 
email via a slave you would need the settings.. where do you get those? does 
each KDE app that sends email hold its own settings and pass them in? no, 
that would be silly. so it uses profiles that the user can set up in the 
email kcontrol module.

the issue with then using something like this w/an actual email application 
is who holds the config info? the desktop or the email app? kio_smtp author 
alex does not want to complicate things by allowing both; he feels that a KDE 
email app that keeps its own email profiles seperate from those of the 
desktop is (in the here and now of kde2) a flawed mechanism. i agree. it is 
confusing and unecessary to duplicate this information everywhere. why not 
have it in one place where all apps can share it? and if this is the case 
then why build kio_smtp around a faulty premise such as each app holds its 
own email settings....

> At least I can't see and additional information which is configurable in
> kemailsettings.

that would be because it needs work to complete it, which (as i've stated a 
few times now) i've done some work on and which alex is also interested in 
doing. 

what this would mean for kmail: instead of saving and reading its profiles 
from its own config file it uses kemailsettings to do this. that's it. the 
readConfig and writeConfig methods in the account and ident classes would 
need to fixed up (that's 6 classes as i count resulting in 12 methods needing 
rewriting each (and these methods are small  and simple to boot)) ... some 
additions will need to be made to the kmail config gui for things such as 
SMTP auth passwords (and i've already started on that =)

what this would mean for kcmemail/kemailsettings: surveying what obvious bits 
of information are missing (already done) and adding them to make these 
desktop facilities feature complete (partially done)

this is something that should be fairly easy to acomplish and would then 
centralize and unify the email settings in the KDE desktop. is this a bad 
thing?

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