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

List:       kde-pim
Subject:    Re: [Kde-pim] KDEPIM Needs More TIme
From:       Martin Steigerwald <Martin () lichtvoll ! de>
Date:       2010-06-03 14:02:34
Message-ID: 201006031602.42048.Martin () lichtvoll ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


Hi Ingo et al,

Just got aware of this thread.

Am Sonntag 16 Mai 2010 schrieb Ingo Klöcker:
> On Sunday 16 May 2010, Lindsay Mathieson wrote:
> > On Sun, 16 May 2010 05:19:49 am Ingo Klöcker wrote:
> > > All you will lose is some meta data (e.g. the state of the
> > > messages). Another advantage of limiting the migration to the meta
> > > data (e.g. the information in KMail's index files) is that there
> > > is less potential for migration errors.
> > 
> > That's good to know, sounds reasonable.
> > 
> > How about the config data? Account setup etc.
> 
> Config data is the real problem. It is likely to get lost on the
> migration. As this has always been the case with almost all upgrades of
> KDE PIM (e.g. when the configuration of the sending accounts was moved
> from kmailrc to another file or when the configuration of the
> identities was moved from kmailrc to another file) I don't see why we
> should handle this differently for this upgrade. A possible solution
> would be to leave kmailrc untouched and use kmail2rc for KMail 2, but
> I'm not sure it's worth doing so.

Hmmm, will KMail 2 save the account config data in kmailrc at all? I 
thought settings like POP3/IMAP server and passwords will be handled by 
Akonadi collections then... Only the GUI to set these would be in KMail 2.

But well, maybe I still totally got the complete scope of what Akonadi 
does share between applications and what it does not share.

If the account config is migrated into Akonadi config files, there could be 
the option to leave them in kmailrc as well at least until KDE 4.7 or so.

And I think another option would be simple to implement and help users in 
going back:

Back up kmailrc to kmailrc-kdepim4.4-pre-akonadi or something like that 
and tell the other in a nice dialog about it.

I do have a two-daily rsnapshot backup of the whole ~/.kde with old 
revisions retained for about a month I think, but this would help users 
who do not think about backup themselves. Critical would be, to do this 
just once upon migration and not to overwrite a pre-existing KDEPIM 4.4 
config with an already 4.5 one, but then you could just add some unique 
hash to the filename to avoid overwriting it. Then even if the migration 
happens two times, maybe cause the first didn't fully work and the user 
tries again, then there still should be suitable backups. The file is 
small.

I really would like this generic in KConfig framework, but for now, just in 
KMail will do.

I think if that backup approach is taken, it might be wise to remove the 
account data from kmailrc to avoid having cruft in there and to avoid 
confusion. Cause the user might still think he could have a setting in 
kmailrc that is defined elsewhere already.

Ciao,
-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7

["signature.asc" (application/pgp-signature)]

_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

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