Introduction

This article will introduce you to the basics of DotMSN. How the general structure is and how to embed it in your application. In the articles it is assumed that you are the application developer. DotMSN is programmed in C#. Therefore it is compatible with all the languages the .NET framework supports. By adding a reference to the compiled dll file, either in your visual studio project or directly as a parameter to the compiler, should be enough to get you started.

General

DotMSN is divided into three namespaces:

As a beginner when you start using DotMSN you will probably only need the XihSolutions.DotMSN namespace. This provides most of the functionality you will need, such as connecting and disconnecting, retrieving contacts and creating conversations. The XihSolutions.DotMSN.Core namespace contains the ‘backend’ classes that are used by DotMSN. This namespace is important for application developers that want to leverage the existing functionality of DotMSN. Because the datatransfer functionality is founded on a lot of classes these are separated and brought together in the XihSolutions.DotMSN.DataTransfer namespace. This namespace is also important for application developers that want to directly send data by using the P2P framework.

Across the boundaries of the namespaces there is another distinction between the classes. All classes, except for two, are part of the DotMSN logic classes. These classes each implement their own specific functionality. For example sending data over a network socket, or interpreting incoming commands. These classes are loosely-coupled, this means that they are not aware of each other. In order for these classes to work together as a whole you will need some kind of glue that connects these classes. This glue is already created and defined in two classes: Messenger and Conversation.

These two classes are a façade to the underlying logic classes. They implement some basic behavior such as automatically downloading emoticons, sending the user display image and setting up the framework to accept data transfer invitations. Note that you can get a perfectly working application without these classes, but it might take some time investigating the library before you know how to make this ‘glue’ code. When you are starting with DotMSN it is really suggested that you use the Messenger and Conversation class, because it will give you a headstart.

Messenger and Conversation are using the logic classes to do their job. The instantiated logic objects used in both façade classes are also available to the application developer. For example when you are using the Messenger class you might want to use functionality available in the nameserver handler class (NSMessageHandler), or nameserver processor (NSMessageProcessor). These underlying logic classes are available via properties in the Messenger class. This way you can take advantage of the simple interface of the Messenger class, but if necessary use all features of the logic classes. The same accounts for the Conversation class.

Handlers, processors and messages

These terms are frequently encountered within the library. Below is a short definition of the terms.

A common processor is the socket processor, which sends messages over a network connection. However there are also abstract processors which are just meant to forward incoming messages to another processor, thereby changing the message’s properties one way or another. As an application developer you will deal the most with handlers. These classes implement the protocol and fires events. For example: when the nameserver handler receives a NLN command, this message is handled and the ContactOnline event is fired.

Contacts and contactlist

All information about a remote contact is stored in the Contact class. These objects are in turn stored in a collection class: ContactList. This class provides strongly-typed access to contacts and ensures that only one contact object is available at any time and new contact objects are created when necessary. ContactList provides five enumerators, for every list one and an enumerator for all available contacts. Note that a single contact can be in multiple lists at the same time.

A Contact object contains many properties that gives you information about the remote contact, like telephone numbers, the current name and the contactgroup it belongs to. Via properties you can also access information about the MSN-client used by the remote contact, and the capabilities of its client.