Iris: An MSN Messenger Client with a Cross-Platform Core
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Iris: An MSN Messenger Client with a Cross-Platform Core
Nicholas Murdoch Jacob Young
Department of Computer Science Department of Computer Science
University of Kent University of Kent
nsm2@kent.ac.uk jy8@kent.ac.uk
Abstract (MSN) Messenger protocol utilised by Microsoft’s
standard instant messaging client, MSN Messenger.
Instant messaging has fast become an essential tool Many open-source messenger clients support the
for the common computer user over an array of many MSN Messenger protocol due to MSN Messenger’s
different messaging protocols and instant messenger massive worldwide popularity with the common user
clients. One of the most globally recognised clients is and the main motivation behind the investigation was
Microsoft’s MSN Messenger which utilises the MSN to look at developing a client that has a much broader
Messenger protocol. In developing clients, it is appeal to this user and the factors relating to this. Such
necessary to look at both the requirements of the a client evidently needs to possess properties that many
server and the requirements of the user. This paper other clients do not and forming a software solution
focuses on developing such a client and the factors that is less specific in its target set of users could only
that affect this process. Iris Messenger aims to be achieved through effective portability so it was
provide essential instant messaging features along necessary to look at how software could be designed
with providing a simple environment for users wishing and developed to be as portable as possible leaving
to chat to other users over MSN without the need to scope for unlimited extension. We looked at how we
use Microsoft’s standard client. We explore the design could achieve this whilst still providing the
and development stages and reflect on the technical functionality, usability and coherent graphical user
aspects of the project in terms of the decisions that interface that is essential to the appeal of such a client.
were taken throughout the process of research, The Iris Messenger client would initially be
analysis and implementation of our own Iris developed for the Debian Linux and Microsoft
Messenger client. Windows platforms to demonstrate its portability and
in terms of development tools, it was necessary to
1. Introduction focus on tools unfamiliar to us and more challenging to
utilise in order to provide a solution that reflected the
The rise of the Internet has provided the common requirements and our objectives. Using the ANSI C
computer user with an extremely powerful array of programming language allowed for greater versatility
tools for communication purposes, none more on every level and coupled with the graphics tools
ubiquitous or useable than the instant messaging client. selected for interface design, the Win32 API for
The concept of instant messaging revolves around the Windows and GTK+ for Linux formed a powerful
ability of computer users to converse over a connected means of developing lightweight and efficient
network in pseudo-real time and although the software. With this versatility came increased
parameters of this are infinitely variable, the principles complexity making these tools and underlying
remain constant. The underlying mechanics of Internet concepts far more difficult to understand and begin
“chat” generally involve a designated server with using. This provided us with the greatest technological
which clients exchange requests utilising a set challenge of all.
protocol. This then leads to the server exchanging
messages between clients. Although many different 2. Background and Resources
protocols exist, this paper and the accompanying
documentation focuses on the Microsoft Network The project relied heavily on several core resources
which were utilised at every stage of the design and
development process. Initially, research and analysis and requirement of space. With these properties being
assisted in the formation of the software requirements its main development considerations and very similar
based on the functionality of the client and led to the to those of Iris Messenger, it provided an effective
conception and design of the software model. The model for how the client could be developed and what
basis for these requirements and initial model and the final piece of software should be capable of.
prototype was Microsoft’s MSN Messenger which was
analysed in great detail ([1] and the software itself). 2.3. Protocol Reference
Actually using the software and Microsoft’s online
references generally as analysis tools allowed the In terms of the protocol, research and definitive
features of MSN Messenger to be broken down to referencing was made more challenging by the fact
form a guide to the MSN protocol and the instant that Microsoft do not release details of their MSN
messaging functionality that it supports. This then led Messenger protocols and so it was necessary to
to forming the functionality that our own Iris discover a third party reference for client development
Messenger client would eventually support. It was also which suited our needs. The hypothetic.org page [5] is
necessary to look at the interface requirements and a unique and extensive reference for the MSN
again, Messenger was a possible template on which to Messenger Protocol Version 8 (MSNP8) providing
base initial ideas. As the main inspiration behind examples of code and many possible multiple
design, it provided a subset of features from which we operations on the protocol. It provided details of
could draw. exchanges with the MSN server and the circumstances
under which such exchanges may occur. As an
2.1. Alternative Clients invaluable resource to development of the client, the
hypothetic.org web page [5] was not only an
Fully understanding the MSN Messenger incomparable guide to specific protocol commands, it
functionality and forming requirements around it also detailed solutions to problems and common
required the further analysis of third party open-source protocol errors. It was indispensable throughout
MSN Messenger clients which demonstrated the development and will undoubtedly continue to be
versatility of the MSN Messenger protocol through referenced for maintenance and extension.
extending the functionality offered by MSN
Messenger. They also allowed us to see some of the Utilising this array of resources aided the design
limitations that Microsoft’s client imposes and to look and development process leading to the conception of
at ways in which these limitations could be removed if the project’s primary objectives and its intended
necessary. Mercury Messenger [2] with its extensive achievements.
list of features illustrates how functionality can be
realistically extended and the further implementation 3. Aims
involved in this. Gaim Messenger client [3]
demonstrates a unique interface which has also The project had several aims which were derived
contributed to design and interpretation of Iris. from the initial analysis and investigation, in order to
Looking at these clients simply provided a contrast achieve our main objective, we aimed to become
enriching the influences of design and development far familiar with implementation tools that we previously
more than analysing a single client could have done. had little or no experience of using. Initially, it was
necessary to look in detail at the ANSI C programming
2.2. Miniaim language and to become comfortable with developing
in it. This process had to be repeated with the graphics
In terms of development considerations and the tools for interface development and the aim was
motivation to build a piece of software with broad similarly to become comfortable with and learn how to
appeal, we analysed another open-source client use these tools in a development environment.
possessing the required properties of the Iris In addition to this, the most important aspect of
Messenger client. Miniaim [3], although it does not building an MSN Messenger client was handling the
support the MSN Messenger protocol favouring Messenger protocol and although an extensive
AOL’s (AIM) protocol, Miniaim provided us with a knowledge was not necessary for this purpose, a basic
unique example of a client similar in concept to our grasp of the protocol and its operations proved to be
own. Miniaim is a considerably lightweight piece of essential.
software, designed to be very efficient in its operationFinally the overall main objective of the project was field of instant messaging and the operation of the
to design and develop an MSN Messenger client using MSN Messenger protocol. In addition, for
the knowledge we had gained and the tools that we had development purposes, gaining the ability to use tools
learned to use. This objective was formed with of which we had no real experience has been greatly
versatility at its core, analysing third party Messenger advantageous. Overall, in terms of the knowledge we
clients revealed many inefficiencies which would have gained from designing and developing Iris
exclude certain sets of users and thus reduce the broad Messenger, the project has been successful leaving
appeal of the client considerably. We decided that this considerable scope for extension in the future. The
appeal should encompass a variety of users but focus following technical content sections set out the overall
upon non-Microsoft users, those users that prefer third results and scientific and technical achievements of the
party non-Microsoft authored software and perhaps project illustrating the development work that has
running lightweight operating systems with hardware contributed towards the initial release of Iris
incapable of supporting inefficient and expansive Messenger.
software.
Evidently any client has to be portable to satisfy this 4.1. Language:
type of requirement and this portability was a primary
consideration for development. Software inefficiency There were several programming languages suited
often introduces limitations in terms of the hardware to this task. When deciding on which language to use,
that it will effectively run on and some third party we considered the following points:
Messenger clients require considerable disk space to
install due to the way in which they have been written. Efficiency: MSN requires several connections to be
This was a scenario that we attempted to avoid. We felt open to the Internet, which users have noticed can
that the solution to the problem was to strip down the cause the application to use up a lot of resources as a
implementation tools in order to develop a piece of result. As such, we needed a language that was fast and
software that could be considered lightweight but efficient so as to compensate for this.
remain robust.
In light of this, such a client had to be versatile and Graphical User Interface: we required a language
prove to be efficient in functional use whilst being that had GUI Toolkits available for it for both Linux
lightweight in its resource requirements. This client and Windows, the two main platforms we were
had to be portable or cross-platform in order to have a developing for. Ideally a language that had toolkit
broader appeal to the common user and provide a support on any Operating System would be best for
simple yet effective graphical user interface for the writing any kind of truly cross-platform client. We
common user. The decision was made to develop Iris considered also implementing a text-only interface, but
Messenger for two initial platforms: Microsoft decided that the time and resources were simply not
Windows and Debian Linux due to their wide spread available to devote to developing a third UI.
use and to demonstrate full portability. It had already
been decided that Iris would be written in C but Challenge: We were both eager to develop our
interface development to fit over the top of this would understanding of unfamiliar languages, and as we
be undertaken using the win32 API for Windows and undertook a similar project in the previous year
GTK+ graphics for Linux to retain versatility and (although not nearly as complex in protocol terms as
satisfy development considerations. In addition the the MSN protocol), we wanted to use a different
client was to be developed with unlimited scope for language for variation.
extension so that porting it to additional platforms is as
uncomplicated as possible in the future. This left us with several options:
4. Technical Details Sun Microsystems Java: We are both very familiar
with Java, having utilised it to write a chat server the
In technical terms we were able to achieve a great previous year. However, as such it would have been
deal in the timescale available considering the size of trivial to transfer that knowledge into developing an
the development team and the complications that the MSN client quickly, which defeated our aims. In
project experienced. Extensive analysis and research addition to this, the Java windowing toolkit AWT
coupled with the design and development stages led to looks outdated, and the newer toolkit Swing is well
us gaining a great deal of technical knowledge in the known to use considerable system resources. It also
lacks a familiar look because it does not use nativeFigure 1. Initial redesign of the Iris Buddy List Figure 2. Second redesign of the Iris Buddy List
widgets. Although we were not developing for the language that didn't fully support the object-oriented
Apple MacOS, we did bear in mind that this is a design model.
possible extension of the project, and Sun's version of
Swing is unpopular with Apple users as it does not We decided to use C to develop Iris Messenger,
respect the MacOS style of locating the menu at the This was due to the versatility and efficiency it
head of the screen in addition to other such provided and for the challenging aspects pf
inaccuracies. implementation, but also due to the two ideal toolkits
available fro the supported platforms. Of course, C++
C++ / C#: Neither of us had programmed with C++ or would have allowed us to write in those toolkits simply
C#, which made them both reasonable suggestions for by using the C subset of C++, but we wanted to keep
developing in. C# however is not a favorite amongst the code base in a single language to avoid over-
Linux users, which really excluded it from being complicating the task.
considered. C++ was a good option with regards to
development for non-Microsoft users because it is a 4.2. GUI Design
well known and popular language. It also had the Qt
window toolkit available to it, used predominantly in The design of Iris' GUI was an iterative process. As
the K Desktop Environment on Unix (KDE). C++ is we did not aim to implement all of the MSNP8
also a fast language, and has several compilers features, we couldn't simply design a GUI that featured
available for it. all of them and restrict or conceal any unavailable
features. As such, as more functionality was added to
C: Again, both developers had had limited experience the client, the design of the GUI was modified and
with C programming although it was always altered. Figures 1 and 2 for the Linux version of the
considered. It is a very fast and efficient language client show how merely adding some buttons required
since it compiles practically line-by-line down to a small shift in design. This is demonstrated when
machine assembler. C had the advantage that the native considering the Iris image moving to above the main
Win32 API is implemented in it, and there was also a set of buttons, to help enforce the relationship between
Unix toolkit available, The Gimp Toolkit (GTK), the functionality they offer and the main buddy list.
which is used predominantly in the GNOME Desktop Keeping the Iris image below the buttons may have
Environment. C also presented us with a considerable inferred a lack of interaction with the main buddy list.
challenge; we were very much used to the object
orientated approach to programming, so it would be 4.3. Experimental Work
interesting to learn how to program efficiently in aAs mentioned, it would be impossible to implement example if a buddy changed status, they might want to
every aspect of the MSNP8 protocol in the given time- produce a window, or change some text in the buddy
frame, so we had to prioritise and include functionality list, print a message to a chat window with that person,
that would be most important to a potential user of the or set up some kind of automated message to that user.
system then implement this functionality first. The original design of Iris' architecture was slightly
This was slightly skewed by our capabilities, for more fragmented, as shown in Figure 4. It was
instance webcam conferences might be a desired expected that socket code and “Terminal” (UI) code
feature, but even a large-scale client such as Trillian would be separated. However, as we discovered when
[6] took over a year to back-engineer and implement looking at GUI tools, they are very closely linked,
this. In addition, certain components and features since windows use calls like poll() themselves to listen
could not be implemented until others were completed, for signals. So the same function in the platform-
for instance file transfer operations needed chat specific code would determine which callback
capabilities first, since the invitation to transfer a file is functions to use for both GUI events and networking
sent using the standard MSG messaging functionality. events similarly.
We came up with a rough ordered list of
functionality, sorted by importance and feasibility to
implement:
• Log into the Notification Server.
• Look at the user's Forward List (aka Buddy List).
• Chat with another user.
• Add, remove, block, and unblock other users.
• Change display name and mark oneself as Away
from the computer.
These were the defining aspects which, when
implemented, would allow us to declare Iris as Beta
Version 1.
4.4. Architectural Design
Figure 3. Final architectural design of Iris
Iris' Architecture is designed such that the main
core of the program – which handles sending data and
receiving data from the server and deciding what to do
with it – is isolated from any machine-dependent code
that is used to display the GUI, set up networking
select()/poll() interfaces (which are implemented with
the window toolkits), and so on.
To allow Iris' core to work without any knowledge
of the platform-specific code, there has to be an
interface which the GUI & Networking layer
implements. Iris provides a set of function headers in
its main header file which it expects to be implemented
by the external code. Some of the methods can feasibly
be left as simple declarations; for example, the
function for setting a buddy's changed status is void Figure 4. Initial architectural design of Iris
extn_set_buddy_status (char* login,
char* status);, which could be left blank if (for
whatever reason) somebody was implementing a front 5. User Evaluation and Testing
end for Iris that didn't include the capability to show
buddy statuses. The functions were named quite We believe that the best way that any program
generically to give any developer freedom over what could be tested for bugs and user interface problems is
their interface should do in any particular event, for to release a hopefully-stable version to the common
user, and have them report back with any problemsthey discovered. This is generally referred to as Beta other user is part of a conversation when it is invited to
Testing, and relies on there being a Beta (hopefully- one, and neither does it provide any functionality for
stable) version to distribute. However, due to time inviting additional users into a conversation.
restraints, we were not able to release any fully
functional beta version of the Iris Messenger software Support for Buddy Icon: This is a popular aspect of
at this stage. As a result, the testing undertaken was MSN Messenger and also helps to make the chat
largely based on the Alpha versions of code, internally. windows more visually interesting.
If, for instance, we produced the code for a new
button, we would launch the software, and attempt to File transfer: This is a very useful feature enabling
find a circumstance in which it didn't work by carrying contacts to share files without requiring space on a
out a series of functional tests. For example, the web server.
Remove Buddy button might do something unexpected
if a buddy hadn't been selected from the buddy list as In addition to the above, it is also worth bearing in
yet. Drop down boxes such as Set Status should have mind that, although MSNP8 is the most recently
all options tested to make sure no minor coding documented version of the MSN Protocol, there is also
problems had occurred. At other times, bugs were MSNP9 and MSNP10 in use by the standard Microsoft
more obvious, with the dreaded Segmentation Fault MSN client, both of which are yet to be openly
hampering code half way through a log-in cycle. In detailed. It would be interesting to discover how the
that case, it would be a matter of immediate correction most recent protocols work, although the use of them
once we had established where the program was going is limited until Iris reached a stage where it could
wrong. utilise the newer functionality to a satisfactory degree.
As for User Interface design, it would be imperative
to collect some feedback from users as to how intuitive 7. Conclusions
they found our program to use. Evidence suggests that
some people prefer Iris' buttons at the top of the buddy The project has been relatively successful in
list window, whereas others would rather have set of achieving the original aims that were set out in the
menus providing functionality. Human Computer analysis and specification stages. Although in terms of
Interface (HCI) testing should be used to determine if physical software, the initial Linux release of the client
the method of operation is obvious enough and would does not satisfy all of the requirements that the project
also be useful to test to see if our informative and error specification outlined, the development process has
dialog box messages were helpful or plainly confusing. been extremely rewarding in terms of the knowledge
For HCI testing, we would set up a list of scenarios that both developers have gained. The initial release of
that we think users may follow in the program and the client (Iris Messenger beta01) provides a very basic
observe a user as they attempted to perform these subset of Microsoft MSN Messenger’s functionality
scenarios, watching for confusion and encouraging and the process of developing it has been highly
them to describe what they think of the interface as challenging in the time available. The Windows
they progressed. The results from this sort of testing release of Iris is delayed due to ongoing difficulties in
could be fed immediately back into design utilising the selected tools for interface design and the
modifications. client has been set back. In its current state, the
Windows component does not implement any of the
6. Future Development required networking to connect with the MSN server
and although a basic interface is in place it is relatively
There are many ways that Iris could be taken limited in its functionality. Taking into consideration
forward in the future. Only the basic operations of the the factors that have influenced the project such as
MSNP8 protocol have been incorporated in the current complications with protocol operations and constraints
version and so there is considerable scope of future on the development team, the final product (Iris for
extension. Some of the more obvious desired Linux) is satisfactory as an initial release. Iris
functionality is detailed: Messenger in its current release cannot really be
compared with alternative clients that have had many
Support for group conversations: This would likely releases and thorough beta testing over a considerable
involve minor alterations to Iris' architecture, since a amount of time. It would require a more solid beta
one-on-one chat is simply a group chat with only two release before any functionality could be fairly
users present. However, Iris currently assumes that no compared and contrasted.Although the idea behind the project itself was not 8. Acknowledgments
particularly original in terms of what is already
available to the user, it did provide an opportunity for We would like to thank our project supervisor, Bob
learning and experiencing a style of development that Eager (R.D.Eager@kent.ac.uk) for his continued
we were not previously used to. It is the experience guidance and help to us throughout the year.
gained that is the most important aspect in undertaking
a project of this nature and it is important in retrospect 9. References
to consider the approach that we took to completing
the task. Considerable analysis and understanding of [1] http://www.imagine-msn.com/messenger/default2.aspx?
the basis is necessary before any structural locale=en-gb, the MSN Messenger homepage.
development can begin to ensure that possible
complications will always be accounted for. In [2] http://www.mercury.to, the Mercury Messenger
addition, a willingness to learn and push oneself homepage.
towards a new ways if working is essential when
undertaking a task on this scale. Iris has always been [3] http://gaim.sourceforge.net, the Gaim Messenger client
developed with possible scope for extension and homepage
addition of new layers of functionality because this
[4] http://miniaim.net, the miniaim homepage
intended to be part of its versatile appeal as a client.
Having been designed to be fully portable ensures that [5] http://www.hypothetic.org/docs/msn, the primary
in the future, it can eventually be extended onto unofficial reference for the MSN Messenger protocol.
additional platforms without constraint.
[6] http://www.ceruleanstudios.com, The Trillian homepage.You can also read
