The natural history of a software application, its life story, was for a long time known only to those behind the walls of the company who owned it. If one moves from working entirely with commercial software, to the world of free and open source software, it is quickly evident that projects evolve out in the open, where any major change in their direction or personnel is public knowledge. If an application is “forked,” or split off into two projects with two distinct teams, then that too is announced far and wide.
Pronto (http://www.muhri.net/pronto), an MUA (Mail User Agent) written entirely in Perl, is the result of such a fork. It is the descendant of CSCMail (http://www.cscmail.net), whose author decided earlier this year to initiate a rewrite of CSCMail in C, the lingua franca of Unix computing. The balance of the CSCMail team, (everyone except its principal author,) remained dedicated to the Perl version, and Pronto was born as a fork of CSCMail. The readme file included with Pronto’s source code provides some of the flavor of the event:
- “…several of us did not think it was time for CSCMail to make the leap [to] C and just enjoy hacking in Perl. So, we continued development of CSCMail in Perl, and just called it Pronto to distinguish the [Perl} effort from the current efforts of the developers of CscMail.”
Like Gmail, reviewed in the last installment of this series, Pronto is coded using the GTK (Gimp ToolKit) GUI library (http://www.gtk.org), so it runs easily on the Gnome desktop or, minimally, requires the GTK libraries. Hence it is window manager/desktop independent; the author’s copy of Pronto can be usually found running on a KDE 2.0 desktop. And, like Gmail, Pronto uses the MySQL database to handle message storage, sorting, and searching chores. Pronto takes its database connectivity one step farther than Gmail; while Gmail is limited to MySQL, Pronto can also use the PostgreSQL database, and will, in the absence of an SQL database, default to the time-honored but inefficient CSV (comma separated variable) file format. Indeed, the Pronto home page declares: “[Pronto] uses the Perl DBI interface now, for database flexibility. You can now use any Perl DBI compliant database with Pronto!. Not just Postgres.”
A familiar hallmark of good Unix and Linux applications is that they are initially somewhat tricky to set up, but once properly installed, they run very reliably. If they ever they need to be reconfigured or reinstalled, a return “refresher” trip to the documentation is often required; it’s easy to forget the setup details of an application that never requires any fussing once it’s installed. Pronto has this characteristic, although much of the trickiness of its installation has been alleviated by a clever Perl install script. A “manual” installation from the source code tar ball is possible, but since Pronto brings together three of its host’s major software systems, Perl, MySQL, and Gnome, it has some unusual software prerequisites, and the Installer, as it’s termed, will automatically retrieve almost all that is needed to meet these prerequisites.
Debian users who are following “Woody,” the current “unstable” or developmental tree, can simply “apt-get pronto” and be off and running. Also, there are debs in Woody for the MySQL and PostgreSQL Perl modules. Users of other distributions may find packaged versions of Pronto, but this author can only vouch for Debian’s. Unfortunately, the gnome-perl bindings required by Pronto are not available in deb format, but for the typical Debian user, getting and installing these will present no difficulty.
The Installer requires an active Internet connection, since it downloads the needed software on the fly, including Pronto itself. The installer script can be kept anywhere in the file system, because it will always create its “build” directory in /root/prontobuild/; as root superuser, start the Installer like this:
# perl ProntoInstaller.pl
First the gnome-perl bindings are downloaded and installed, since it is unlikely these are already on the host, even if it has a fairly complete Gnome desktop already installed. (Again, Pronto does not require Gnome.) Then the host’s Perl installation is examined for the needed Perl modules, and if any are missing they are downloaded and installed. Lastly Pronto itself, either in tar ball or rpm format, is downloaded and installed; if tar ball is chosen there is an opportunity to set Pronto’s installation prefix: for instance, /usr/local/.
There is one glitch in the installation process, but it is easily circumvented. Pronto needs the HTML::Parser Perl module, but this module has had a recent rewrite and needs to query the user during its build about some new experimental Unicode support. The Installer will hang at this point and display a message, “Waiting for user input,” but it is easy to get back on track. First issue a ‘Ctrl-C’ to halt the Installer, and then manually install HTML::Parser by doing the following (say “no” to the query when it pops up):
# cd /root/prontobuild/HTML-Parser-3.13/ # perl Makefile.PL # make # make install
Then restart the Installer. It will note HTML::Parser’s presence and move through the rest of the installation. As of ver. 2.2.2 (2.2.1 is the current) this detour will be rectified.
Pronto’s message viewing pane can be either a plain text widget, or one of three possible HTML widgets. All four widgets will display message quoting in color, with different colors for different quoting “depths.” The default HTML widget, GtkXmHTML, built automatically by the Installer, will display clicked URLs in a user-defined Web browser such as Netscape. One of Pronto’s nicer features, its “minibrowser,” requires either of the other two HTML widgets, GtkHTML or CscHTML. The minibrowser is a scaled down HTML file viewer, which some users will prefer for viewing URLs found in e-mail messages rather than launching a full scale browser such as Netscape. GtkHTML can be installed by revisiting the /root/prontobuild/ directory, CDing to the gnome-perl/GtkHTML/ subdirectory, and issuing the commands used above to install the HTML-Parser module. CscHTML can be downloaded from its home page at http://www.cscmail.net/cschtml. Interestingly enough, the author found that the older CscHTML widget rendered some HTML better than GtkHTML, but by all accounts the latter is the more advanced of the two.
Pronto’s Installer will not fetch the Perl modules that allow Pronto to “talk” to MySQL or PostgreSQL. It is the user’s responsibility to install these, but there is no mystery to it. The needed modules are identified in Pronto’s documentation, and fetching them from a CPAN mirror is straightforward. As noted, Debian users who are following Woody are all set in this department. The philosophy here is to take the user by the hand only as far as the basic installation, which defaults to CSV storage. Beyond that, users are on their own. Pronto’s lead maintainer, Maher Awamy, explains: “I’d rather the user interact with things that are other than Pronto’s components separately; I really don’t want to mess with their db’s or db servers and then have something bad happen. Basically I’d rather the user RTFM ;-)”
The major Linux distributions provide pre-compiled packages of MySQL and PostgreSQL. Unless one is a SQL purist, MySQL is most likely the best choice for the user who only needs a SQL database for Pronto. There are clear directions in Pronto’s installation instructions for setting up either MySQL or PostgreSQL for use with Pronto. Pronto will run just fine without a SQL database, but the old CSV file format will slow things down markedly, especially as the size of the message base increases. If an SQL engine is used, then Pronto’s speed, with only a few exceptions (for example, full text searches) is not a function of the size of the message base. The author has tested Pronto with a database of 16,000 messages, and searches on message headers are stunningly fast, on the order of a few seconds.
Pronto takes advantage of its SQL database to provide “virtual” folders; these are, technically speaking, SQL “views” of the message base. Many mail user agents provide filtering of messages into various folders, but these folders are typically separate files or subdirectories. In Pronto’s virtual folders, messages are accessible as if they had been moved into folders, but they remain in a single unified SQL database. This will not suit every e-mail user. It is, however, just the thing for any user who, say, follows and archives a dozen or more e-mail lists and tires of keeping track of, and archiving, a dozen or more distinct files or subdirectories.
Pronto’s folders can be defined in terms by the headers (To/Cc:, From:, Subject:), the account originating the message (Pronto can retrieve mail from multiple accounts), or message scoring. For message searching, Pronto uses a unique type of virtual folder, which allows any search criteria can be saved as if it defined an ordinary virtual folder. This folder is updated whenever messages are added to the database. Search folders can be defined in terms of the usual headers, message scores, or message “newness.” Up to two criteria, plus a full text search term, are allowed for each search. Searches can be one-time affairs, or saved as virtual folders. The main Pronto window shown in Figure 1 illustrates the use of message age to define a virtual search folder that holds all newly downloaded mail. Whenever an e-mail account is polled for new messages this folder is updated. As messages are read, they are “removed” from this folder. Catching up is simple; after choosing the New Arrivals folder, choose “Select all” from the main Edit menu and then “Mark as read” with the right mouse button pop-up menu.
Not Your Father’s E-mailer
SQL databases for e-mail storage are often considered overkill. The author’s extensive use of two such MUAs suggests this is a prejudice, more speculative than empirical. The presence of MySQL (or PostgreSQL) is completely transparent to the user. Also, it is likely that messages stored in SQL tables are at least as secure as those in typical Unix spool files, if not more so, and they are certainly more secure than messages stored in any of the myriad idiosyncratic databases that many authors of GUI e-mail packages seem compelled to invent. These authors often guarantee that a crash of the e-mailer sends the message base to the Transporter Room, which forwards it to the Cosmic Byte Bucket. Finally, for large collections of e-mail, say anything over 5,000 messages, most e-mailers begin to slow down in direct proportion to the number of messages, so for anyone who is fond of keeping tens of thousands of e-mails around, Pronto clearly deserves a close look.
This brief overview has only touched on Pronto’s array of features. The program is in active development, and cannot be said to be 100% bug free. But its mailing list is home to a small, active group of enthusiasts, including Pronto’s principal author, so help is available. The free software movement is alive and well in Pronto’s corner of the cyber world.
About the author: Robert Bernstein ([email protected]) is a freelance writer specializing in the Open Source and Free Software movements. He has edited Linux texts for Macmillan Publishing, and written technical articles for Caldera Systems. Over the years he has worked as a land surveyor and as a Licensed Mental Health Counselor in Massachusetts. A life-long New Englander, Bob now lives in Esmond, Rhode Island, a village he describes as “apple orchards, cow pastures, and Victorian textile mills that speak to you from a hundred and fifty years ago.”