the system can provide the server parameters once and have the system
The increment to be developed in this prototype is the persistence of user
information. The main information to be kept consists of the mail server
parameters: the server name, the username and the password. They must be
provided once, when the user is registered with the system, without the need
to repeat them at each connection as in the previous prototype.
In addition, since the mail is private, we need to add some security. The
users need to authenticate themselves with the system to use the stored
information. For this application we use a simple security scheme: users
authenticate with a username and password.
In addition to providing a user-friendly application we need to store the
user's full name, since the username can be just a given name.
All the information concerning a user forms the user profile that is made
up of the following items:
username and password;
The user interface must provide the ability to register new users with the
system and to modify the profile of an existing user.
The structure of this prototype is far more complex than the previous one.
The user interface should allow the registration of new users and the modi-
fication of profiles. The profiles are persistent; therefore they must be stored
in a database.
In the previous prototype we noticed that some sections of code are
repeated in several places; an example is the code that deals with the mail
server. In addition, to avoid larger repetitions, we store the folder in the
session context. This is inefficient because it keeps a connection to the mail
server open, thus consuming resources. This can be a threat to the scalability
of the system. We need to factor the common code to avoid repetitions and
How do we factor the common code?
We introduce a new package, UbiMail , that contains the classes where we
put the common code. This package forms a sort of layer that simplifies the