[kdepim-users] kmailrc content, was: KDEPIM migration from KDE4 to KDE3.5?

[Ingo Klöcker]

On Thursday 12 January 2012, Martin Bernreuther wrote:
> Am Dienstag, 10. Januar 2012 schrieb Ingo Klöcker:
> > > (BTW: It's strange that you find metadata like the number of
> > > emails ("TotalMsgs") in a "rc" configuration file.)
> > 
> > It's not really that strange at all. Caching of those numbers
> > allows displaying the numbers without having to determine the
> > actual numbers (which might be incorrect the next second anyway).
> > Determining the actual numbers might be slow or even impossible
> > (e.g. if the IMAP account is currently unavailable). Okay, the
> > numbers could be cached in some other, non-configuration file
> > (e.g. in a database as Akonadi does ;-) ), but using the already
> > existing configuration file was just easier. Developers are
> > generally lazy. Why else would they make computers do the boring
> > stuff for them. :-)
> 
> It's not the fact that KMail is caching data, I'm complaining.
> Storing this caching data in kmailrc is IMHO bad design.

I fully agree. I just explained why this bad design came to be.


> I'd prefer KMail to open kmailrc "read only" at the beginning
> to get the configuration and "read/write" only if you change
> the settings.

Yeah. Would be nice. But that's not how KDE's configuration file 
framework works. KMail is doing nothing special here.


> I have kontact open all the time and in the
> past I even didn't close the application shutting down
> the computer. This was quite comfortable. Since I
> had some problems with KMail freezing I also had
> to kill the application.
> Recently my kmailrc was damaged and I'm not sure,
> if kmail was killed while writing these files. It's not
> a big loss, if caching information is lost, but it's bad
> to loose the whole configuration. Splitting the
> configuration and caching data also has the
> advantage that different locations might be used,
> e.g. the configuration might come from a NAS
> and the cachling data from a local disc.
> 
> If I restore a kmailrc file from a backup, will the
> wrong caching data then just be thrown away?

No, but eventually it will be replaced by correct data. As I wrote above 
any cached value can become wrong the second after it was cached.


> Is it really that hard to open, read and write another file?

No.


> Does KMail not even use more files than kmailrc to
> get all the data it needs?

Yes, it uses other configuration files as well.


> I probably should run a kmail strace to check that,
> but it's too late today. (Once I had a corrupted
> emailidentities file and KMail did freeze,
> if  I tried to write an email.)
> 
> But don't get me wrong. First I understand,
> if someone wants to be "lazy". But I don't think
> that this is the right  adjective for KMail and other
> Open Souce developers, since they wouldn't even
> start to do all that work then...

I've been KMail's maintainer for a few years so I know pretty well what 
I'm talking about. Just because we developers do all that work does not 
mean that we always do a beautiful design. Sometimes we simply use 
what's already there like in the case of the configuration file which 
did already hold all kind of information for each folder.


> I'm just still not convinced about the design decision here.

Well, with the advent of Akonadi this whole discussion is moot anyway 
because nowadays Akonadi's database is used as cache for this 
information.


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/kdepim-users/attachments/20120112/e551d575/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users