1. Problem
A messaging system can be a very complex
topic as there are many facets to be covered. The basic system, though,
should be able to manage messages, senders and recipients, folders to
contain the messages, and email notifications. In our case, we are going
to try and keep things simple where it makes sense to do so. But in one
area, we will do things in a more complicated approach simply because
it will result in less wear and tear on the overall system.
Rather than follow a standard email messaging system
where each person gets a physical copy of a message, we are going to
build our system in the same way that the MS Exchange server works. We
are going to make one copy of a message and subscribe users to that
message. So rather than have 50 messages for 50 recipients, we will have
one message and 50 recipient subscriptions.
The next complexity (although
not that complex) lies in building a WYSIWYG (what you see is what you
get) messaging editor. For this feature, there are many open source
WYSIWYG editors; we will use one of those to save us a bit of time. We
will be using the most popular editor — XINHA. This editor can be
downloaded for free here at http://xinha.webfactional.com/. You may have seen this editor already. It is widely used across many popular community sites.
2. Design
Let's take a look at the design of these features.
Messages
Messages are the core of any messaging
system. Generally, a message would contain details on the sender of the
message, receiver of the message, and other metadata about the message,
subject, and body. In our case, the message will be more simplistic. Our
messages will contain the sender, subject, body, and the data sent. It
will also contain details of the type of message (message, friend
request, and so on).
We will need to create a page that allows a user to
compose a new message. This interface should also allow a user to add
his/her friends easily rather than force them to remember everyone.
Also, this interface should allow a user to quickly snap together some
HTML without ever having to look at HTML. This can be accomplished with a
WYSIWYG editor.
Rec&;&;ipients
As w&;&;e have already discussed that we are
going to move some of the complexity away from the message, following a
subscription model instead, you will find that most of the complexity of
this system lies around the recipient concepts.
In this case, the recipient subscription is what will
be contained in a folder and will have a read status. With this design,
we can remove some of the burden from our database. The overhead of
doing this of course means that we now need to manage our data more
smartly as it is kept in many pieces.
A more simple design that would result in more copies
of data to be managed would be to create one message for each
recipient. This is easier as each message can easily be deleted and
moved around without having to worry about the copies of that message of
the other recipients. Having said that, if the message is quite large,
and more importantly if we were to allow file attachments, most of the
copy would be identical for each recipient. This would quickly bloat
your database!
