Beautiful Code [166]
my $mail = $parser->parse($tmpfh);
return $self->cluebat (ENOSUCHMSG, 0 + $msgnum) unless $mail;
$mbox->update_message($msgnum,$mail);
}
In a similar manner, MIME skeletons are cached for all messages listed by the user through the message list view. The rest of the code continues to work as before, by operating on the cache for all read operations. Now we have IMAP compatibility, without compromising the features afforded by my mail store or modifying the main code much.
Mail store replication would need to be worked in again because the switch from Mail:: Folder::SQL to an IMAP server for the mail store meant Replication::Recall couldn't be used for replication. But in any case, Replication::Recall wasn't the most elegant or easy to implement replication system, and the Recall library had been rewritten in Python, making my Perl interface to the earlier C++ implementation obsolete anyway.
In hindsight, I spent a lot of time on the replication functionality, which had to be scrapped, and I probably would have been better off not bothering with replication at that stage. On the other hand, it did teach me a lot that will come in handy when I get down to implementing replication again.
Market forces and changing standards mean that application software is always evolving, and much of the beauty of such code from the programmer's point of view is certainly in how easy it is to adapt the code to ever-changing requirements. Cryptonite's object-oriented architecture makes it possible to implement major revisions with ease.
Secure Communication: The Technology Of Freedom > Speed Does Matter
11.10. Speed Does Matter
With the Cryptonite mail store, performance had been quite snappy, and most mail store operations had been independent of mailbox size. But with the switch to IMAP, I noticed some major slowdowns with large mailboxes. A little profiling revealed that the performace bottleneck was the pure-Perl Mail::IMAPClient module, which I'd used to implement the IMAP capability.
A quick benchmark script (written using the Benchmark module) helped me check whether another CPAN module, Mail::Cclient, which interfaces to the UW C-Client library, was more efficient than Mail::IMAPClient. The results showed clearly that I'd have to redo the IMAP code using Mail::Cclient:
Rate IMAPClientSearch CclientSearch
IMAPClientSearch 39.8/s -- -73%
CclientSearch 145/s 264% --
Rate IMAPClientSort CclientSort
IMAPClientSort 21.3/s -- -99%
CclientSort 2000/s 9280% --
I probably should have thought of benchmarking the different modules before writing the code with Mail::IMAPClient. I'd originally avoided the C-Client library because I wanted to keep the build process as simple as possible, and Mail::IMAPClient's build process is definitely simpler than that of Mail::Cclient.
Fortunately, the switch from the former to the latter was generally quite straightforward. For some operations, I noticed that IMAPClient could do the job better than C-Client without much of a performance penalty, so Cryptonite::Mail::Service now uses both modules, each to do whatever it's better at.
A program like Cryptonite is never "finished," of course, but the code is now mature, robust, full of features, and efficient enough to serve its purpose: to provide thousands of concurrent users a secure, intuitive, and responsive email experience while helping them effectively protect the privacy of their communications.
Secure Communication: The Technology Of Freedom > Communications Privacy for Individual Rights
11.11. Communications Privacy for Individual Rights
I mentioned at the beginning of this chapter that making secure communications technology widely available is a very effective means of protecting individual rights. As this recognition is the basic motivation behind the Cryptonite project, I'd like to end with a few observations on this point.
Cryptographic technology can, among other things:[]
[] See http://www.idiom.com/~arkuat/consent/Anarchy.html and http://www.chaum.com/articles/Security_Wthout_Identification.htm.