Data Structures used for the UVIC Messenger
This section will talk abut the data that are needed to drive the UVIC Messenger.
Since data are shared between clients and the server, it is good to have
a clear design of how the required data are structured. Almost all the work
done by the server is take in data and pass out data, this section will also
cover our design of the server. Please note that the (A1), (P1), etc. symbols
after the sentences indicate the requirement that drives this design.
User
(Requirements met: A2, A3, A12, P1, P2, P7, R11, R12)
Place of storage: Server
The Server must contain user information. The minimal list of user data that
is needed includes
full name,
password, student number or employee number, user type, user status and user
name. The student number is so that we have a unique id
for each user and student number is chosen because it will also allow us
to query the course database for courses that the user is registered in.
Since this messenger is for academic use and not purely for fun, users need
to be able to identify each other and that is why the server must have the
full name of students. User type is kept to handle the implementation of
private discussion and other permission issues. User status is
kept to implement alternate messaging method. When a user's status is offline
server should let other user to send message to this user by email. Finally
the password and user name is for the purpose of allowing users to login.
This password and username should be the same as the user's netlink password
and id because we need it to retrieve the users' email and for unity sake.
Although the server keeps all these info, it doesn't mean any user can view
them all. Items like employee number and password are viewable only by that
user and server administrator and student numbers are only visible to user
with type professor or higher.
Login Process works by the client sending a hello packet with
their username. The server will respond with either an error packet with
payload of a string that tells why the username failed. (For example, user
not found or user banned or even user account expired due to failure to pay
tuition.) If there are no error with the username, the server will send
a ack packet. Upon receiving the ack packet the client will send an auth
packet with their password as payload. The type of encryption used here can
be chosen by the implementers. Server will either respond with a ACK packet
with payload of how many new email user has or ERR packet with payload
as the reason why user can't login. Next server will send client a STATUS
packet with payload as what status are available for the client to be in.
For example. on leave, off campus, etc.
Optional data
(Requirements Met: A12)
Picture is an optional function/data for the UVIC Messenger. User picture
is not generated automatically. A user must upload a picture to the server
if they wish to use this feature.
Statistic
(Requirements met: A6, A7)
Place of storage: Server
Statistic are collected every time a user logs in. A unique number is generated
to match with this user, so that actual user name or student number is not
stored permanently. This is for privacy reason. For a period of time a user
name is match with the unique number but the statistic data will not be visible
by anyone but the administrator until a preset time. This is so that daily
or weekly or monthly statistic can be kept. When the preset time expires the
user name is removed. The statistic table should keep the amount of login/logout
a day, duration of a session, number of message posted, number of forum visited,
list of forums visited and number of forums/discussions created.
Contact List
(Requirements met: A1, A3, A4, A9, P4)
Place of storage: Server
Contact list should be kept at the server, because it is less likely to lose data
then personal workstation. Also list kept on server, will allow the server to easily generate new contact lists
for the user. The server will connect to the course database and add to user contact list sections labeled
with the course number. Within these sections the contacts will be the professor and other students in that course.
Calendar
(Requirements met: P3)
Place of storage: Server
The data of the calendar is stored as events. The server will automatically.
grab user's course information and transform them into events. Event's data
includes start time, duration, place and day. Conflicts can be computed by
comparing if a event's start time is within the range of another event's start
time and duration.
Discussion
(Requirements met: R11)
Place of storage: Server
Discussion data are generated when a user request the generation of a new discussion
group. The data include discussion name, created date, last active message,
minimal user type to join, list of invited users (this can be in the form
of a course number) and list of current active users. When a user creates a
discussion, the user provide either a minimal user type to join or a list
of invited users.