--===============6022439269432016662==
Content-type: multipart/signed; boundary=nextPart2881883.fxoAPMDVR8;
 protocol="application/pgp-signature"; micalg=pgp-sha1
Content-transfer-encoding: 7bit

--nextPart2881883.fxoAPMDVR8
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Thursday 12 January 2012, Martin Bernreuther wrote:
> Am Dienstag, 10. Januar 2012 schrieb Ingo Kl=C3=B6cker:
> > > (BTW: It's strange that you find metadata like the number of
> > > emails ("TotalMsgs") in a "rc" configuration file.)
> >=20
> > 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. :-)
>=20
> 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=20
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.
>=20
> 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=20
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.)
>=20
> 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=20
I'm talking about. Just because we developers do all that work does not=20
mean that we always do a beautiful design. Sometimes we simply use=20
what's already there like in the case of the configuration file which=20
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=20
because nowadays Akonadi's database is used as cache for this=20
information.


Regards,
Ingo

--nextPart2881883.fxoAPMDVR8
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEABECAAYFAk8PWk4ACgkQGnR+RTDgudgQzwCff5eA8u/JmIbdzWa3yx68RP45
hAkAoOBlocOMdY6yUaU/zre4J/4ikPc/
=Fp/B
-----END PGP SIGNATURE-----

--nextPart2881883.fxoAPMDVR8--

--===============6022439269432016662==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
KDE PIM users mailing list
Subscription management: https://mail.kde.org/mailman/listinfo/kdepim-users

--===============6022439269432016662==--