| only for RuBoard - do not distribute or recompile |
The general flow through this Web-based system won't be much different from other email clients. A diagram showing the system flow and modules is shown in Figure 27.1.
As you can see, we will first require a user to log in, and then give him a choice of options. He will be able to set up a new mail account or select one of his existing accounts for use. He will also be able to view his incoming mail—responding to, forwarding, or deleting it—and send new mail.
We will also give him the option of viewing detailed headers for a particular message. Viewing the complete headers can tell you a lot about a message. You can see which machine the mail came from—a useful tool for tracking down spam. You can see which machine forwarded it and at what time it reached each host—useful for assigning blame for delayed messages. You might also be able to see which email client the sender used if the application adds optional information to the headers.
We have used a slightly different application architecture for this project. Instead of having a set of scripts, one for each module, we have a slightly longer script, index.php, that works like the event loop of a GUI-driven program. Each action we take on the site by pressing a button will bring us back to index.php, but with a different parameter. Depending on the parameter, different functions will be called to show the appropriate output to the user. The functions are in function libraries, as usual.
This architecture is suitable for small applications such as this. It suits applications that are very event driven, where user actions trigger functionality. Using a single event handler is not very suitable for larger architectures or projects being worked on by a team.
A summary of the files in the Warm Mail project is shown in Table 27.1.
Let's go ahead and look at the application.
| only for RuBoard - do not distribute or recompile |