From kmail-devel Fri Sep 12 00:07:28 2003 From: Neil Williams Date: Fri, 12 Sep 2003 00:07:28 +0000 To: kmail-devel Subject: Re: Archiving messages from KMail X-MARC-Message: https://marc.info/?l=kmail-devel&m=106332524413311 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============1261341266718401==" --===============1261341266718401== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_E5QY/e3wN6G6er6"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit --Boundary-02=_E5QY/e3wN6G6er6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline On Friday 12 Sep 2003 12:14 am, Ingo Kl=F6cker wrote: > In general KMail reacts allergic to other applications messing around > with KMail's folders. At worst you risk loosing all messages in a > folder. If the messages are already archived what's the loss? :-)) As long as KMail= =20 isn't running when MHonArc reads the mail I can't see a problem - MHonArc i= s=20 only reading the files, it doesn't change any files unless the configuratio= n=20 is changed. I just run MHonArc when I'm preparing for a network backup - I= =20 can't run KMail during that process anyway. MHonArc does no more than mkiso= fs=20 =2D it reads the directory and copies the files. MHonArc takes less than a= =20 minute to archive a month's email from three mailing lists (>1,000 messages= )=20 =2D mkisofs takes close to 10 to do the backup and cdrecord 2 to write to C= D.=20 If I can't leave the LAN alone for 14 minutes in a month there will be=20 something very wrong! Plus it means that I can archive my mail regularly and let KMail delete it = on=20 expiry or manually once I've verified the backup CD. (Incidentally, the=20 single key shortcuts are very useful for that, despite the understandable=20 protests - I'd like to re-enable them in the config if/when they are=20 removed.) > Furthermore CP probably doesn't want to give up the possibility to read > and search the archive folders with KMail. Why use two frontends (one > for current mail and one for archived mail) to access your mail? Personally I need to correlate all email with HTML/PHP/Perl pages/scripts=20 in-progress anyway because the archive relates to my web design work, so it= =20 suits me fine. I wouldn't say that MHonArc is a frontend - it's a backend=20 script that could even run via cron. The front end is the HTML browser -=20 there can't be much wrong with KHTML as a second method of access! It is incredibly inefficient to have to read all the contents of the folder= =20 just to view the folder list as in KMail. Much better to have a separate HT= ML=20 archive with a single threaded index HTML page that can be browsed and then= =20 load each individual HTML page as and when needed. > At least I haven't yet seen a HTML frontend for a mail archive which is > comparable to a mail client. Usually searching sucks, navigation in I truly believe that MHonArc is far superior to any email client search -=20 that's from continuous use of both methods over a long period. (Otherwise I= =20 wouldn't have recommended a separate solution.) I write the search scripts myself - I use MHonArc because it's implemented = on=20 one of the sites I run as webmaster. I use Perl to write the scripts, the=20 results include an abstract of the actual email contents (not the first par= t=20 of the page) and there are the usual Boolean and case sensitive/insensitive= =20 pattern matching. Even without customised scripts, grep can do anything KMa= il=20 can do - neither offer any real help constructing the regular expression so= =20 there's no advantage from the GUI in that respect. Take a look at http://www.dclug.org.uk/ for a real-life example of MHonArc = in=20 action - try that search script too. My local one can include regular=20 expression pattern matching but that's not easy to implement securely on a= =20 www server. There's a threaded and date-order index list for each individua= l=20 archive going back to 1999. > threads sucks, attachment handling sucks. Threads I find are FAR better in MHonArc than KMail. MHonArc copes v.v.well= =20 with mailing list threads - especially when someone replies to an existing= =20 thread using a new message, losing the reference list. KMail orphans the=20 offending message at the top of the list - MHonArc uses pattern matching to= =20 find the best match. It also copes much more effectively with people who ha= ve=20 their PC clock set to last year etc. After comparing KMail and MHonArc on a= =20 daily basis for a personal threaded archive spanning the last 3 years (must= =20 be >20,000 messages in total by now), MHonArc wins hands down. I haven't done a lot with attachments, MHonArc can file them separately and= =20 include a link in the final HTML but as most of the mail to be archived is= =20 mailing list stuff, the only attachments I get are signatures. MHonArc does= =20 cope admirably with JPG and other image format attachments via the same HTM= L=20 link to a separate file mechanism. > Regards, > Ingo If you haven't seen a frontend to compare with KMail, take a look at a back= end=20 that beats it, fair and square. =2D-=20 Neil Williams =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D http://www.codehelp.co.uk http://www.dclug.org.uk http://www.biglumber.com/x/web?qs=3D0x8801094A28BCB3E3 --Boundary-02=_E5QY/e3wN6G6er6 Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQA/YQ5EiAEJSii8s+MRAol0AKDXYMsAqqnf4QqcWvRwXYjle50i5wCgjkJP apI5UOZYb0CfQVStpe0J24k= =+NT3 -----END PGP SIGNATURE----- --Boundary-02=_E5QY/e3wN6G6er6-- --===============1261341266718401== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ KMail Developers mailing list kmail@mail.kde.org http://mail.kde.org/mailman/listinfo/kmail --===============1261341266718401==--