[Evolution-hackers] sync vs async in invokations of sa-learn

Andrew Cowie andrew@operationaldynamics.com
Tue, 10 Aug 2004 18:17:57 +1000


--=-vnVbH8G4a/85Z0CWq3NZ
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

I know that you hold up updates to the UI when processing and learning
junk, and understand why.*

However, it's obvious in evolution/mail/em-junk-filter.c that someone
took enormous effort to separate the act of injecting messages vi sa-
learn from having sa-learn rebuild it's databases. (ie, use of --no-
rebuild when learning, and then later a call to sa-learn with --
rebuild).

It would seem that the later action [em_junk_sa_commit_reports()] could
happen in the background asynchronously. There's no need for the UI to
wait for that as well, is there?

AfC



* [user experience report: it's a tad slow, especially if filtering new
messages on first evo startup in the morning. The reason for holding
updates is so that messages don't move out from underneath the user, etc
on filtering, but isn't that what happens when deleting? If machine (or
evo, for that matter) is busy at all, then there is a lag between
pressing delete and UI repaint. No biggie. I would have thought the same
applies to repaints after Junk moves. IMHO]

--=20
Andrew Frederick Cowie

OPERATIONAL DYNAMICS
Operations Consultants and Infrastructure Engineers

http://www.operationaldynamics.com/

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBGIS1LVETDFf2570RAptvAJ45OARkyetWlvl9KweR/C2cdnuwFQCggueC
hmUw13VcMm7NEvxPMnfEhlE=
=UTLO
-----END PGP SIGNATURE-----

--=-vnVbH8G4a/85Z0CWq3NZ--