[Kde-pim] Kmail2 doesn't remember passwords

[Ingo Klöcker]

On Wednesday 07 September 2011, ianseeks wrote:
> On Tuesday 06 Sep 2011 23:13:05 Ingo Klöcker wrote:
> > On Monday 05 September 2011, ianseeks wrote:
> > > On Monday 05 Sep 2011 13:53:40 Valentin Rusu wrote:
> > > > On 09/05/2011 09:24 AM, ianseeks wrote:
> > > > > hi
> > > > > 
> > > > > If you don't use KDE Wallet, kmail2 never remembers your ISP
> > > > > logon password even though i tick the box to remember it.
> > > 
> > > yes, but why can't kmail2 remember it like kmail 1 - it seems
> > > like a bug to me.
> > 
> > We chose to reduce the unnecessary complexity caused by providing
> > two different ways for storing the password. We chose to reduce
> > this complexity by removing the old, totally unsafe, legacy way of
> > storing the password
> > 
>  > We should have removed it as soon as KWallet was
> > 
> > available, but we didn't. In retrospect, this was an oversight
> > which has cost us quite some maintenance effort. With KMail2 we
> > finally made a clean cut.
> 
> it would have been (i think) better if the changes happened
> invisibly. Getting questions like <akonadi resource require....> is
> completely meaningless to the lay person, its developer talk.

You are absolutely right. Akonadi shouldn't be visible to the normal 
user.


> The
> passwords could have been slipped into Kwallet without the user even
> knowing or caring by using the exisitng kmail1 dialogs.

Maybe. But only if the KDE Wallet hasn't been disabled by the user.


> > > > > Is there any way i can force it to remember and stop
> > > > > prompting me
> > > > > for it every time?
> > > > 
> > > > Yes, by activating KDE Wallet :)
> > > > 
> > > > That's the intent of KWallet : you give only one password when
> > > > a first application needs to use a secret (like your
> > > > password). The wallet will remain open and  subsequent secret
> > > > access will automatically be granted to requesting
> > > > applications, eliminating multiple password prompts.
> > > 
> > > I understand that but having a choice is a fundemental feature of
> > > open source. Being forced into using kwallet is more of a feature
> > > of a company like Apple or MS
> > 
> > You are misinterpreting this principle.
> > 
> > You have several choices:
> > - KMail is Free Software. This means you can create (or make
> > somebody else create) your own version of KMail which stores your
> > password in the way you prefer.
> 
> I think if i had the ability/money to do so, i would fork as the
> configuration and some of the of kmail2 features seem overkill, such
> as all the akonadi stuff. I've not been able to get my head around
> the purpose or benefits of it.

Some distributions still provide packages for KMail1. Maybe there are 
even some packages of kdepim 4.4 (which includes KMail1) available at 
http://software.opensuse.org/search for your distribution.


> > - You can use any other Free Software (or even non-free) email
> > client you want. We do not stop you from using/installing other
> > software (like Apple does on several devices).
> > 
> > If offering choice costs too much additional effort (in
> > maintenance, in further development because one has to make sure
> > that one does not break any of the options, in testing, etc.) then
> > it is in the best interest of the developers, the maintainers and
> > the users to reduce complexity. Usually, less complexity means
> > more stability. Would you rather have complex software offering
> > lots of choices or would your rahter have stable software?
> 
> I definitely prefer stable but to me the Kmail2 configuration looks
> more complex than kmail1.

Yes, it is more complex because it depends on quite a few components. 
Ideally, this complexity would be hidden from the users. Currently, 
that's not really the case.


> I think if kmail2 imported the kmail1
> data/config data and then transparently merged it into the new
> system without any user intervention, it may have caused a few less
> painful experiences.

That was the plan. Unfortunately, many people are having problems with 
the migration. Apparently, we underestimated the diversity of the 
configurations that need to be migrated. We hope to be able to make the 
migration more robust, but it's difficult because a lot of the problems 
that occur in the field are not understood well enough.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20110913/350f33b6/attachment.sig>
-------------- next part --------------
_______________________________________________
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/