The client core is derived from the pop3Connection class handling the details of command/reply-exchanges following the client side of the POP3 protocol. The overall handling of a complete pop session, including recovery from errors, is built on top of that. However, the decision what mails to load from the server is delegated to an external object following the interface laid down in popClientMsgClassificatorBase. Base of the decision are the mail headers. The classificator is given to the core through the specification of the option pop3Client:classificator. The task of storing the messages which were loaded from the server is outsourced as well. Here the option pop3Client:storage is used to specify the actual storage object, which has to be derived from popClientStorageBase.
Currently only one classificator is implemented, acceptEverything. From the name alone it should be clear that this classificator actually does no classification at all. It alwas decides on retrieving the mail it was given.
On the other hand we have six storage systems, namely dirStorage, fileStorage, memStorage, multiStorage, smtpStorage and triggerStorage.
apps/popeye is a complete pop client built around this core, using the all accepting classificator and all storage systems with the exception of fileStorage. The structure is as in the following image
The functionality of triggerStorage is used to start a flist operation in my mailreader, which is ExMH, created by Brent Welch, also written in Tcl. This operation scans all known mail folders for new mail which is then displayed. Without that ExMH would have to poll every so often to be up to date.
The statemachine used by pop3Client to control the pop session looks like this:
This image is available as postscript too. It should be read together with the actual code.
Generated by AutoDoc 2.4 at 09/14/2000, invoked by Andreas Kupries