---

1 Introduction
Some communication between members in a software project leaves traces (such as emails or protocols from meetings) that make it possible to retrieve information later on e.g. what was agreed. Other communication channels leave no trace (e.g. informal meetings, telephone conversations, and chat sessions over the Internet). If something is agreed upon in when communicating through such channels, this information will be lost and can give rise to conflicts later. The task of this project is therefore to store relevant chat sessions in a way so that this information can be easily retrieved later.

1.1 Purpose of this document
The purpose of this document is to describe the forthcoming of this project. The document describes the outcome of the project. This document is a part of a document series intended to describe and document the project details and forthcomings. No one of the documents in this series will give a full view of the project. This document however is the first overview.

1.2 Intended Audience
Our intended audience is:
• Steering Group
• Project Managers
• Project staff
• Contractor and customer

1.3 Scope
This project will identify the possibilities of making messenger programs context aware, and define an architecture that supports a number of instant messenger tools, and implement a general framework, database and specific components needed for different messengers.

3 Milestones
The milestones of the project are checkpoints for controlling that the project is on time. There are only a few delayed milestones, and overall the project is on time. The first milestone was one week late due to some startup issues depending on communication techniques, i.e., how to communicate between Zagreb and Västerås. The following milestones were met until after the Christmas vacations. Due to the vacations the project stalled for a week, and a few milestones were delayed, however it did not affect the project in all. Below is a summary of all milestones, when they were planned to be met, and when they were actually met.

4 Project Results
The project has been successful in the creation of a messenger tool for recording messages. Their have been very few slight delays and few changes to the original plan. Some of the original requirements have not been fulfilled. The cause of the deviation from the original requirements is related to some unknown restrictions in the messenger model. In section 4.1 an estimate of the requirements compliance is presented. Each requirement is explained in detail in section 4.1 and a short explanation to the compliance to the customer requirements.

4.1.1 Build upon an existing messenger tool
We feel that we have succeeded in making the recorder build upon an existing messenger tool by selecting an architecture that build upon plug-ins. We use a set of libraries (dll’s) which makes the recorder messenger-independent. The libraries we use attach them selves to the IM program, which make the architecture robust and IM independent.
4.1.2 Store chat sessions for later retrieval
Messages are stored in a database for later retrieval. If a connection to the database isn’t possible or corrupt, the recorder will sore messages to a local media (local hard drive). Next time the connection to the database is present, the locally stores messages will be sent to the database.
4.1.3 Allow searches in a user-friendly user interface
Searches are possible.
4.1.4 Robust
Part of the robustness is discussed in section 4.1.2.
Running state of recorder program is independent of Instant Messenger. The recorder program works independent of if the messenger hangs or shuts down.
4.1.5 Non-intrusive
The recorder requires a minimum of user intervention. The only time the user needs setting up anything is when modifying the recording filter, and when starting the recorder. A tray-icon is present when the recorder is started. We do not have any tags on each message to show what messages are stored.
4.1.6 Honor privacy
Filter options are present to honor the privacy by letting the user decide what sessions (conversations) should be stored. See also section 4.1.7.
4.1.7 Be secure
Encryption is implemented to avoid abuse and corruption of the stored data. This also enforces privacy since no-one can read or alter information stored locally.
4.1.8 Designed for future integration in the web-project
The database used in the project can easily be merged together with the database of the web-group. The web-group would have to decide how to represent and use the data.

5 Technical issues and difficulties
5.1 security firewall
The server that runs the database used a firewall, and we were permitted only to use one port for establishing a connection, further on, we weren’t allowed to establish a direct connection to the database, the DB only accepted tcp connections running from the localhost interface.
The only viable solution to this problem was making a local daemon that runs on the server and accepts tcp connections on a designated port and routes them to the dbms
5.2 Redundancy in messages
What if both users decide to record the conversation? To solve this problem the tables are created in such a manner so to support simultaneous recording of messages from both sides this adds to security in the way that potential chat participators can establish a rule that only messages that were recorded twice. And the solution adds stability in a way that if both chat partners record a single session, every message has more chance to be recorded if networking problems occur. Alternative solution could have been to write a lot of code to check if messages coincide.
5.3 Server side processing
To handle compatibility between daemon and IM handled, we incorporated the message processing in our connection daemon. This solution has drawbacks, namely that the program has lost on flexibility. The benefit is that the daemon acts as a filter for the communication. An alternative solution could have been to use a procedural language (SPL). However, using a pure java daemon seemed to add to the general portability.
6 Project experiences
The project has been very rewarding in many aspects. Both in terms of an interesting problem to solve and the difficulties involved in managing a project with members at different geographical locations. The project groups have been rather small, which have increased the possibility to compare distributed project experiences with experiences from regular projects. Furthermore we have not had any big cultural differences, nor have we experienced any time difference.
6.1 Positive Experiences
The positive experiences from the project related to the geographical distribution are discussed below.
• Project meetings - Despite the geographical divergence, the meetings have worked very well both with video conferences, electronic mail and instant messengers.
• Cultural exchange – the whole group found the cultural exchange very interesting and rewarding.
Positive experiences related to the course in general are discussed below.
• The course wasn't confined to academic laboratory work, it was more comercial and realistic.

6.2 Improvement possibilities
Possibilities to improve parts of the course related to the geographical distribution are discussed below.
• Diverging schedules - Since all participants have had other activities besides the DSD course, it has sometimes been somewhat hard to schedule meetings off scheduled time, especially during the exam periods.
7 How to prolong the lifespan of this project?
The recorder is very modularly built and is very easy to extend with new IMs. To add more IM modules and perhaps put a finishing touch on the interface would make this a very useful product.


More

---