[MyMH] First Steps to a New Email Client
Monday, October 17th, 2005 11:50 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
flwydAfter playing around a bit with mh's support for mbox, I realized it doesn't meet my needs. For instance, you can't refile from one mbox to another, which means it really won't work for my Pluggable MUA plan of accessing my email.
On Saturday, I therefore decided to start working on what I'll call pmh, or perhaps pclmi ("pickle me") for Perl Command Line Mail Interface. I googled perl email and discovered there's More Than One Way To Do It. The first hit was The Evolution of Perl Email Handling, written by Simon Cozens, the main author of the Email::* modules. The Email:: approach is to be as simple as possible, but no simpler. It's small, lightweight, and easy to understand without flipping back and forth between manual pages. I implemented crude but functional versions of scan and show. Unfortunately, Email::Folder hides too much in its API. Email::Folder only presents an iterator, no random access. However, the mh-style approach depends on random access, so you can do scan and then show 1234.
This evening, I tried the older, more featurefull, and more complicated approach, Mail::Box. I converted my test commands to the Mail::Box API with its random message access and discovered something interesting:
Using Email::*, showing message 1 of 1920 takes about 8 seconds. Showing message 1920 takes about 8 seconds.
Using Mail::*, showing message 1 of 1920 takes about 14 seconds. Showing message 1920 also takes about 14 seconds.
It would seem that the random access API afforded by Mail::Box doesn't buy anything when accessing mail in mbox format. (I haven't yet tried maildir.) Furthermore, a scan with Email::Folder on the 1920 message box takes 11 seconds and starts working immediately, while using Mail::Box it takes 45 seconds, including an extended pause at the beginning.
8 seconds is an unacceptably long amount of time to wait to see a message in a (for me) modestly sized folder (and yet, mutt changes to a folder and shows a message much quicker than that...). I may be forced to abandon the every operation is a separate process mantra and shift to a command interpreter which can hang on to folder contents. Alternatives include coming up with a crafty indexing approach which can be abstracted as a folder (view), or trying my performance luck with the javax.mail API.
On Saturday, I therefore decided to start working on what I'll call pmh, or perhaps pclmi ("pickle me") for Perl Command Line Mail Interface. I googled perl email and discovered there's More Than One Way To Do It. The first hit was The Evolution of Perl Email Handling, written by Simon Cozens, the main author of the Email::* modules. The Email:: approach is to be as simple as possible, but no simpler. It's small, lightweight, and easy to understand without flipping back and forth between manual pages. I implemented crude but functional versions of scan and show. Unfortunately, Email::Folder hides too much in its API. Email::Folder only presents an iterator, no random access. However, the mh-style approach depends on random access, so you can do scan and then show 1234.
This evening, I tried the older, more featurefull, and more complicated approach, Mail::Box. I converted my test commands to the Mail::Box API with its random message access and discovered something interesting:
Using Email::*, showing message 1 of 1920 takes about 8 seconds. Showing message 1920 takes about 8 seconds.
Using Mail::*, showing message 1 of 1920 takes about 14 seconds. Showing message 1920 also takes about 14 seconds.
It would seem that the random access API afforded by Mail::Box doesn't buy anything when accessing mail in mbox format. (I haven't yet tried maildir.) Furthermore, a scan with Email::Folder on the 1920 message box takes 11 seconds and starts working immediately, while using Mail::Box it takes 45 seconds, including an extended pause at the beginning.
8 seconds is an unacceptably long amount of time to wait to see a message in a (for me) modestly sized folder (and yet, mutt changes to a folder and shows a message much quicker than that...). I may be forced to abandon the every operation is a separate process mantra and shift to a command interpreter which can hang on to folder contents. Alternatives include coming up with a crafty indexing approach which can be abstracted as a folder (view), or trying my performance luck with the javax.mail API.
