Corporate email and calendaring solutions <br/>embedded in a strategy for <br/>Computer Supported Cooperative Work

Corporate email and calendaring solutions <br/>embedded in a strategy for <br/>Computer Supported Cooperative Work Fachhochschule Gießen - Friedberg
Fachbereich Mathematik, Naturwissenschaften und Informatik
Diplomarbeit
Corporate email and calendaring solutions
embedded in a strategy for
Computer Supported Cooperative Work
Zur Erlangung des akademischen Grades
Diplom-Informatiker (FH)
Diplomand
Timotheus Pokorra, Matr.-Nr. 625252
Betreuer
Prof. Dr. Berthold Franzen ( FH Gießen - Friedberg )
Andrea Wachter ( Operation Mobilisation ) Erklärung zur Diplomarbeit
Gemäß § 5 Abs. 8 der Prüfungsordnung des Fachbereichs MNI, der Fachhochschule Gießen - Friedberg
Hiermit versichere ich, die vorliegende Diplomarbeit selbständig verfasst und unter ausschließlicher Verwendung der angegebenen Literatur und Hilfsmittel erstellt zu haben.
Gleichzeitig versichere ich, diese Diplomarbeit in gleicher oder ähnlicher Form weder veröffentlicht noch einer anderen Prüfungsbehörde vorgelegt zu haben.
Siegen, 15.11.2002
Timotheus Pokorra I want to thank Prof. Dr. Berthold Franzen for his willingness to support a diploma thesis abroad and his hints how to make the diploma thesis complete.
I enjoyed the time in Carlisle and want to thank Andrea Wachter and the Linux Team for their help and ideas.
I'm thankful to my mother who always supported me, regardless whether I studied in Gießen, Ireland and England.
My most grateful thoughts belong to God, who gave his son Jesus for me, and has given me the strength, wisdom and joy to deal with all the different situations in life and in the work for this diploma thesis. This diploma thesis should give an overview of the current situation of the group calendaring market. Group calendaring is a Groupware application, and Groupware is the implementation of the studies of the field "Computer Supported Cooperative Work". Therefore this environment will also be investigated to show that there is not only group calendaring, but even more applications that help groups working together.
This diploma thesis will show some of the standards involved in Groupware, and the fight for survival of proprietary solutions and the creation of the Internet Calendaring standards are investigated.
A closer look to one open source groupware solution will show that still a lot of work has to be done. The reader will realise how difficult it is to build an application with a clean structure and readiness for future extensions when several people are voluntarily working on a project. is a christian mission organisation that has about 40 offices in different countries. These offices are responsible for the activities of OM in their country or neighbouring countries. Especially during the summer months the number of involved people increases due to special outreaches. The whole administration and organisation is done by those offices. The office of the in Carlisle provides, beside other help and tools, the OM Standard Linux Server. The Linux team develops and maintains this configured distribution of Redhat Linux. The goal of this standardised server is to have one solution for all offices with the same configuration. That simplifies the support by the Carlisle office and means that not every office has to figure out the best suitable Linux configuration.
One problem is the very different situations of the offices. Some offices are based in poor countries with a minimum of technical infrastructure, e.g. there is only an expensive dialup connection to the Internet. There are 2 ocean-going ships as well, with each 300 staff and 50 workstations on board. Other offices are based in Europe and the United States and can use a really good technical infrastructure. Smaller offices often have different needs than huge offices.
The aim of the computers in OM is to support the people working together, and to give them more time for doing the real job which is described by OM with these words: "[...] bring a message of hope to the peoples of the world. [...] we love Jesus and we want others to have the opportunity to hear about Him. Operation Mobilisation works in more than 80 countries, motivating and equipping people to share God's love with people all over the world. OM seeks to help plant and strengthen churches, especially in areas of the world where Christ is least known." The task was to collect the requirements concerning an email and calendaring solution with support of Palm synchronisation to provide groupware functionality for the existing OM Standard Linux Server. Furthermore a general survey of existing solutions on the market should be given. Using this survey, the group of solutions that best fit the requirements should be specified, and finally one chosen solution needs to be integrated into the server. The first chapter contains this introduction.

The second chapter investigates the term "Computer Supported Cooperative Work". It refers to the possible applications of CSCW, and describes the underlying technologies involved. Also the relation to Multimedia and Pervasive Computing is mentioned. The new term "enterprise application integration" also is remotely connected with CSCW. This chapter describes the ideas behind this diploma thesis.

In the third chapter the main focus is on the functionality that is expected from email, group calendaring and synchronisation. The standards used to realise the ideas are named and described.

The fourth chapter consists of two parts: First there is the description of how the analysis was realised, and in the second part an outline of the current market situation is given. So this chapter contains information about the implementations of the ideas of chapter 2 by using the standards described in chapter 3.

The fifth chapter covers the specific requirements and solutions for OM, and contains an outlook for future computer support for OM.

A summary of the diploma thesis is in chapter 6.

The appendix holds some tables and installation instructions that were created during the work on the topic.

All information can also be found on the enclosed CD-ROM. The diploma thesis document and the results of the analysis are originally in XML format and were converted by PHP programs to well structured and linked HTML documents.
All texts taken from the Internet are also saved on the CD-ROM, and they can be easily accessed via the links in the HTML version of the diploma thesis. This chapter describes some of the ideas that build the basis and the background of groupware products.
The terms "Computer Supported Cooperative Work" and "Groupware" are explained during this chapter, but also other terms like "Pervasive Computing" and "Enterprise Application Integration" are mentioned, which influence groupware applications.
The main focus is put on scheduling and on calendaring because this was the field of CSCW that was most required by OM. In 1988, Greif described in this way: "CSCW is an identifiable research field focused on the role of the computer in group work".
Wilson wrote in 1991: "CSCW is a generic term which combines the understanding of the way people work in groups with the enabling technologies of computer networking, and associated hardware, software, services and techniques."
What is then the relationship between CSCW and groupware? In the words of Borghoff and Schlichter, "CSCW includes the universal scientific research field, groupware deals with the respective practical system solutions of collaborative work" . And further on they say: "Groupware refers to software systems supporting teamwork and integrating theoretical foundations achieved by CSCW research" .
Johansen states that "Groupware can involve software, hardware, services and/or group process support" .
Therefore groupware is the name for computer systems whose functionality is based on the results of the CSCW research.
In the following parts of this second chapter often the term "groupware" is mentioned, although the title of the chapter is "CSCW". But that is just the right way: In fact the topic of CSCW is to define the term "groupware" and to fill it with appropriate meaning. The goal of groupware is to support groups or teams in their work. It is assumed that these groups have a "common task (or goal)" that they try to achieve by working together.
Borghoff and Schlichter write about different types of groups: They call groups that only communicate via computer "electronic groups", in contrast to "electronically supported groups" which have both personal contacts and electronic communication . The goal of CSCW is to "[make] distributed communications as efficient as face-to-face communication." .
The groupware system is supposed to "provide an interface to a shared environment" . That means that the members of the group are accessing the same objects in the environment at the same or different times. That is especially a requirement when these objects have to be changed by different persons until the objects are in the aimed state.
There are different degrees of a shared environment and a common task. That means there are a lot of very different kinds of groupware applications, which are investigated in a further chapter.
Therefore, all groups of people that work towards a common goal and want to use electronic communication to deal with a shared environment, need groupware applications in order to work and communicate fast and efficiently. Grudin's extended groupware classification according to time and space is shown in the following table . Grudin extended the classic classification by the factor predictability.

Space/time	Same time (synchronous)	Different times (asynchronous)
Space/time	Same time (synchronous)	predictable	unpredictable
Same place	face-to-face meeting	shift-work	blackboard
Different places (predictable)	video conference	email	joint editing of documents
Different places (unpredictable)	mobile phone conference	non-real-time computer conference	workflow management

Here is just one example how to read this table: Email is a groupware application that assumes different predictable places, which are the different mail servers that normally are not in the same place or on the same machine, but their position is predictable because they don't move. If you want to send someone an email, you just send it to his email address which is associated with his email server. The sender and the receiver have access to an specific email at different times: The sender writes it, then he sends it and looses control over the email. He only can read it again if he has a copy of the mail, but cannot change the instance of the email anymore that he sent away. While the time difference between the sending and the receiving is not a guaranteed fixed time, the asynchronous access to the email is predictable: When the mail has left the email server of the sender, he cannot access it anymore, and as soon as the email arrives at the email server of the receiver, he has complete control over the mail. So it is predictable that both would never access the mail at the same time and that the receiver would never be able to read the mail before the sender has sent it.
What about calendaring? It would fit in the grid at "predictable different places" and "unpredictable different times". The argument for the place is the same as with the email, because we are again dealing with a server that manages the calendar. The access to a calendar item is asynchronous because all users can read and write to a calendar independently, according to their rights on that specific calendar. One user can add a new appointment, two hours later another user reads it, and again 30 minutes later the first user cancels it. You cannot predict the chronological order of different people accessing the calendar or one of its items. This chapter gives a short description of some application areas of CSCW. It should help answer the question: How can CSCW be used in the daily working life? is one of the most used groupware applications, but it is only a loose communication link between the group of people using it: People are not forced to answer to requests, and the information contained in different emails is not easy to be organised. Some emails only contain small parts of a discussion, other messages are holding important decisions or profound drafts. Anyway, email systems provide a fast and direct communication channel for text messages and other attached media files.
Groups can use email communication by either sending their mails to a which distributes them to all members of the group that have subscribed to the list. An archive of a mailing list provides the history of past discussions and communication, which helps new members to join the group and to catch up the information that they otherwise would miss.
The with its is a different way of communication. Its main goal is to support distributed discussions. So one of the advantages of newsgroups is that all news or message items are saved only once on a server, and the users can download those items they are interested in. This overcomes the heavy traffic caused by mailing lists, where all incoming emails are delivered to all subscribers. And naturally it provides an archive of written news. There is a clear hierarchy of the messages, but this is also provided with simple mailing lists, when a message has reference tags to previous mails in the thread.
The disadvantage of the usenet is that a newsgroup has to be checked regularly if you are expecting answers to your question or comments to your statement, and you need to remember where in the hierarchy your article was placed.
A is also an application for supporting discussions like the usenet, but it is represented in HTML and is not distributed across the network but runs centralised on one server.
Newsgroups, mailing lists and forums can be moderated, and the names and email addresses of involved users can be hidden. Conferences and meetings are an essential part of team work, because only in a meeting the group can discuss the different views about the goal, talk about how far the group have got to reach that goal, and what actions have to be taken in the coming weeks or months to come even more closer to the solution of the given task.
Borghoff and Schlichter give some more "benefits of group meetings" : Sharing of ideas, modification and synergy of ideas, different people can find problems more easily with an idea than the person that had the idea, encouragement by knowing that you belong to a team, and people can learn from each other.
But there are also problems with meetings described in , e.g. how to partition the time and right of speaking between the participants, how to come up with new ideas when still listening to other's ideas, having not enough self-confidence to speak out new ideas, or some members of the group are dominating the meeting and the others are just passively participating.
Borghoff and Schlichter describe different kinds of conferencing which can be supported by groupware applications in different ways. The following information is taken from if not another source is mentioned.
There are , i.e. all attendees are physically in one meeting room. The use of computers can be helpful in preparing and showing a presentation that helps all people to visualise what the speaker is talking about. A groupware application could also help record the meeting minutes or even more detailed information about the discussion. If necessary, all attendees could be provided with a personal computer so that they can contribute to the collection of information on e.g. an electronic whiteboard at the front of the conference room.
Another type of conference is called . Such a meeting is between people that are not in the same room but can be in another building across the road or on the other side of the world. Borghoff and Schlichter divide this type of meeting in 4 categories: Asynchronous computer conferencing is normally realised by the use of email. It is not required that the people take part in the conference at the same time. This is also called "non-real-time computer conferencing" . Such conferences take a lot of time till they are finished with a usable result, but they don't appear on any schedule. So the danger is to underestimate the time that is needed for such conferences. Shared screen and audio or video connection: The participants can see the same screen and are able to talk about the subject. The identical screen is realised by a data link, and the applications in use should support the principle . This principle enables the attendees of such a meeting to work on the same document at the same time.
There needs to be an additional link between the participants that carries the audio or video information. If the video images are not displayed on an extra screen but integrated into a window beside the window of the shared application on the screen of each participant, this type of conference is called "desktop conferencing" . There is the possibility that there are not only human attendees, but also pieces of software called that act in a programmed manner and can, for example, support the meeting members by searching information about mentioned keywords, or by recording the minutes on their own. These agents could also participate in a face-to-face meeting, but then someone would be required to control the agent which means to type with the spoken information. In an all participants are represented in the virtual space by avatars. Those avatars are virtual characters that are controlled by the hardware that is monitoring the belonging participant. The hardware can be e.g. a microphone for the audio information, or a data glove to visualise the movements of the attendee. Calendaring and Scheduling is necessary to enable a group to organise meetings. Calendaring is the main subject of this diploma thesis, so this topic gets more attention than the other applications of groupware.
This chapter should give an idea about the terms involved in calendaring and scheduling which are used by most applications in the same way. A detailed example of a calendaring standard is described in the chapter 3.3, which is about the Internet calendaring standards. Palen describes in her dissertation the history and the background of calendaring. She states that schedules make "it possible to dependably coordinate with others" . She says there are public schedules, that determine e.g. when shops are open, or when there is a public holiday. Our public schedules are also influenced by nature, which makes the difference of day and night or summer and winter. Personal schedules allow yourself to plan your own time, and they enable the people around you to have access to you on agreed times in order to coordinate action. These schedules don't need a physical representation, they often are just maintained with speech acts.
Palen also dicusses some sociological aspects of calendars and time in general. She says that time is a possession of every person, and people can show each other respect or low regard by either giving time or letting someone else wait .
Another more practical problem is that if management introduces the use of shared electronic calendars, they are the ones who mainly get the benefit from it because it is easier to organise meetings . But it is up to the normal group member to enter all his appointments into the shared calendar which often takes more time than just to maintain a paper calendar . There is a "critical mass" of people needed that maintains their calendars so that group calendaring can be used effectively in an organisation.
Another challenge of group calendaring applications is that some people already use their own personal calendar application with special advantages, e.g. portability if it runs on a , or it supports a special to-do list. Those people have to manage the synchronisation of the different calendars . It is necessary to convince those people how important it is to have shared calendars so that they are willing to take on the additional effort of synchronising.
But calendaring can also be a great help to remind people of recurring personal dates, e.g. birthdays of old friends. That helps to stay in contact, and this is a good social component . Reekes, Vice President of MeetingMaker, a company involved in calendaring software, describes the evolution of electronic calendaring: It started with personal calendars, was extended to group and shared calendars, and was finally developed to collaborative scheduling. The following lines are a summary of Reekes' text .
A personal calendar is in Reekes' definition a simulation "of paper-based day planners" . It helps the user to "track appointments and manage daily tasks". A personal calendar fits together with the idea of . PIM applications started to exist on the desktop of personal computers, and then got their own hardware with the invention of the .
A group and shared calendar is an improvement to the personal calendar because it gives the opportunity to see the calendars of other people in the organisation. So the calendar is not isolated from its environment, but shared inside the organisation. The user of a shared calendar knows about the availability of his colleagues and can therefore better coordinate his own time or the time of the group. The use of group calendaring became possible when client/server technology was becoming cheaper and more common.
Collaborative scheduling allows the user to interact with the other users through the calendar software, and to arrange meetings synchronously and in real time. That means he can invite other persons to a meeting, and immediately get the response from their calendaring software whether they are free at that time or not, and then he can book the time on their calendar so that later attempts of arranging a meeting would realise that there could be already another meeting at that time.
Another source from Alt-N Technologies states that scheduling depends on "current and accurate" personal calendars, otherwise the booking of meetings would not be reliable. It has to be assumed that the free time on the calendar is not already booked by appointments not listed there. The Microsoft Outlook 2000 Online Help defines these terms in this way :
"Appointments are activities that you schedule in your Calendar that do not involve inviting other people or reserving resources."
"A meeting is an appointment you invite people to or reserve resources for."
"An event is an activity that lasts 24 hours or longer."
So appointments are all incidents in which only the user is involved. A personal calendar would only contain these types of entries. Meetings affect at least 2 or more calendars, and often need to be confirmed by the other attendees. An example for an event could be a vacation or a seminar. Sometimes there are extra calendars for the details of a seminar, but the whole happening as one entity is called an event. There are also other components of a calendar beside meetings, appointments and events. People also want to save notes or journals, to-do entries, and alarms in their calendar. These entries can often be linked to real calendaring incidents. Notes or journals help to extend the calendar to be like the personal paper notebook you carried with you, where you wanted to have a notice beside an appointment describing your personal thoughts about it. To-do items describe activities that are not bound to a special date or time, but have to be done during a given period of time. Alarms are useful to be reminded about an event. For example, an alarm can either remember you a day before the event to prepare something for the event, or it can help you 5 minutes before to stand up from the desk and walk to the meeting room. There are different levels of privacy that a calendar can allow to its users. All calendar solutions at least allow the user to mark a single event as private. That means that other people just see that there is an appointment, but cannot see the details. Some programs have all calendars strictly private by default, and allow the user to invite other people and give them different rights to see or change his calendar, or just to show them the time blocks when the user is available. Depending on the level of privacy, people can see if you are available or not available during a period of time, which is also called a time block. A time block can be marked with 4 different states: , , and . "Free" means that you are available at that time, and "busy" means the opposite. "Out of office" also gives the other people the information that you are not available in the given period of time. "Tentative" is something in between. These time blocks can either be shown to the other people as if you were available, or in a different style so that they know you might be available. This kind of property of a time block is used whenever an appointment has no fixed point in time up to which it has to be done, e.g. you just book it for the morning, but if another more important request comes in for a meeting, you can move your personal appointment to the afternoon. Group calendars allow the organiser of a meeting to select the desired attendees/resources and check at which time they are all available. He should see the free and busy times of all attendees/resources and therefore know when people are available or unavailable. The invitation is either sent via email or is directly inserted into the calendar of the attendee. At that point in time, the meeting is in the state "no response". Invited persons can accept the invitation or decline it or set its state to tentative. That means they might attend the meeting when nothing else is more important. Meetings don't only need to be attended by the right people, but also a room needs to be booked, and perhaps some equipment is required, e.g. a projector.
That means that every resource should have its own calendar. There can be a manager for a resource who decides in conflict situations which group or user should get the resource.
If there is a group of the same resources available, the calendaring application should assign a free resource to the request of the organiser.
The , also sometimes called host, is the one person that invites other people to a meeting. He is allowed to change details of the meeting proposal.
The invited persons that join a meeting are called or .
If someone has been invited to a meeting but is not able to attend the meeting, he can ask one of his colleagues or employees to replace himself at the conference. The one who delegates the participation is called the , and the person that is sent to the meeting is the . Another equal name of this role is .
Another role is the one an assistant takes when he is acting on behalf of his superior. The assistant is then called the . He is allowed to manage the calendar of his chief, e.g. to organise a meeting that is held by the chief, but he is too busy to deal with the details of organising the meeting. There are different levels of granularity how to define recurring events. Nearly all scheduling products allow to define daily, weekly, monthly, and yearly events. Some of them also allow to give a day of the week on which the event should occur. Another feature is to give the interval of the event, so it is possible to arrange an appointment that occurs every second Monday. It's even better to be able to combine these attributes, e.g. to say an event recurs every first Monday in a month.
Repeating events often have an end date at which they stop repeating.
The calendaring software should allow the modification of the whole series of events as well as changes to a single event on a special day. There are always two different ways to realise calendaring: A calendaring solution can depend on electronic mail services, and use them to exchange invitations and responses.
In contrast to that, realtime calendaring uses an extra calendar server that holds all information of the calendars of the users, and invitations can be inserted into the calendar immediately. If the user is connected to the calendar server, he sees the invitation at the same time it has entered the server.
The advantage of this solution is that if the mail server crashes, calendaring still can be used, because it is a different server program. Furthermore it supports realtime collaboration: You can be sure that the free/busy times are accurate and that there are no unread invitations that wait for the user to be added to his calendar. Unread invitations are already integrated into the calendar and given the state e.g. "no response".
Another advantage is that the calendar and the email client don't need to cooperate too close, so you are able to use programs from different producers. Sen and Durfee define the following attributes of a meeting:

a set of participants
the owner, also called host or organiser
duration
priority
starting time preferred by the organiser; if it is not completely defined, participants are allowed to propose e.g. the time of the given day, if no special time but only the date is given
the latest possible starting time, also called deadline
latest possible time of scheduling the meeting: It has to be decided to this point in time, whether or not the meeting will take place, and when exactly it is scheduled.
The actual meeting start and end time, which is chosen in the end of the decision process

A personal calendar consists of the following attributes:

the starting date of the calendar
the end date of the calendar
set of time slots, which can cover e.g. an hour or 30 minutes, and the information about what appointment or meeting is planned for this time slot, or if it's free.

There are several possible methods that help in organising a meeting: The organiser can make a proposal which is also called a . Potential attendees can send a which can be positive or negative, or they can request changes of the meeting, e.g. another date or time. The organiser can new details to a proposed meeting, but also attendees or a whole meeting.
It is also a great help for the organiser when he can request free busy information from the people he wants to attend the meeting. When people their free busy details, he can see what times could be suitable for all or most of them.
More details about this topic can be found in and in chapter 3.3. Borghoff and Schlichter describe the use of agents in groupware applications, and they also write about agents helping in scheduling and organising meetings.
At first there should be a short summary about agents:
Agents are autonomous, they are able to act without intervention of the user . They know about their own internal state and about their available actions. An agent knows about the "problem domain" and is able to understand changes in its environment and how to "react appropiately". That means that the agent has its own behaviour.
A special language called was developed at the . This language consists of a vocabulary, a and a .
Agents can be used for . That means that several agents have "to cooperate in order to solve complex problems" . They have to share "their knowledge, goals, skills and execution plans". The complex problem is subdivided into several subproblems, that can be solved by one agent in coordination with the other agents.
The helps to find out which agents can solve what subproblem, and it allows agents to negotiate how to exchange information in order to collaborate. The primary message types are: Task announcement, task bid and task assignment. There are also request, acknowledgement, termination and report messages. There is a manager that announces the problem, and agents can bid their available resources, and the manager decides what is the best bid. Based on that decision, he assigns the appropriate tasks to the bidders .
Now follows the description about how agents are able to solve meeting scheduling problems:
It is assumed that every personal calendar is managed by an agent. The agent of the person that wants to schedule a meeting takes on the role of the manager in the contract net protocol, and sends his announcement with the attributes of the proposed meeting to the other agents, which are responsible for the several personal calendars of the participants. These agents match the proposed times with their set of time slots, and either reply with yes or no or "suggest a new time interval" . The manager collects all the bids and decides whether a solution was already found, or if he has to reannounce the meeting with different time intervals, that better fit to the received bids from the other agents. If the final interval time is sent around, the agent of a personal calendar has to recheck if the time slot still is free, and then he reserves it for the meeting. This category of groupware application is also called "shared information spaces". Appelt writes in that a shared workspace is a "repository of shared information". He states that a system with support for shared workspaces allows the users to upload and download files. It also enables a user to give other users different levels of access to his files. There should also be a version management system that helps to cope with different versions of the same document, which is especially a problem when several people are working on the same file.
Borghoff and Schlichter say there is "separate responsibility" , i.e. it is clear which user is responsible for what parts of a document.
They also compare "mutual exclusive access" against "synchronous access" . With mutual exclusive access, only one person at the time has write access to a document. That is realised e.g. by locks. Synchronous access allows several people to work at the same time together on one document. Here again the WYSIWIS principle applies.
Another type of information sharing is in between those two types of access, it is working with "alternate versions" . That means that several people are working on local copies of the same document, and these different versions of the document have to be synchronised, which often requires manual adjustment to resolve conflicts. The principle was already mentioned several times, and group editors are those applications that realise this principle. Group editors enable several people to work on the same document at the same time. Each one of them sees the same version of the document. If someone changes the document, notification messages are sent to the other users and their screen is updated .
The group editor helps users to be aware of the other persons that are working on the same document, and shows which parts of it are edited by whom. It has to avoid that people are working on the same segment of the document, because then it would not be clear which changes should be applied to the document. So only one user has write access to a segment of the document, but still the other users are allowed to read this segment .
According to Borghoff and Schlichter, the architecture of a group editor consists of the data layer and the operation layer .
The data layer holds the content information with the content of the document including the formatting information. The structural information, which holds information about other users' activities, also belongs to the data layer. The data layer is completed with history information about previous document versions and user information, e.g. the email address.
The operation layer provides the functionality for editing the content and for changing the structure of the document. This layer is responsible for the coordination of updates, in order to have everywhere the same information, and for the coordination of locks that can be set by the user or enforced by the editor application. It furthermore notifies the user about the activities of other users working on that document . When people are working together to achieve a common goal, they have different activities that need to be coordinated. Some activities can only be carried out asynchronously, e.g. when two activities on the same object cannot take place at the same time, because either one depends on the others' completion, or at least one of them needs unrestricted control over the object.
There are some different approaches described by Borghoff and Schlichter :
The "form-oriented systems" concentrate on the document that is forwarded from one member of the group to another, and each of them performs his task on the document. For example two people have both to add a chapter, the third person has to review it, and the boss gives his signature.
A "procedure-oriented system" divides the process of reaching the goal in a lot of different procedures, which are subdivided into several steps. Each member of the group is assigned to one or more procedures. Each step in a procedure receives an information unit, processes it and returns the modified version, so that it can be the input for the next procedure.
"Conversation-oriented systems" try to model the normal interactions between human beings. There are electronic message equivalents for some speech acts, e.g. request, promise, reject, accept, cancel, etc. .
The "communication structure-oriented systems" know about the specific roles that are assigned to the different members of the team, and are able to use this knowledge to bring some order in the processing of work. Borghoff and Schlichter write that CSCW is "an interdisciplinary application domain" . The knowledge and achievements of several disciplines are required to develop and introduce a groupware system that is accepted by all its users in a company.
Computer science provides the necessary hardware and software capabilities. Software designers need to develop applications and user interfaces that can be used in a simple and quick way, so that the users are willing to accept and use the groupware solution. People must see the benefit for themselves and the company from changing traditional ways of work to using CSCW.
Telecommunication technology connects different workstations both inside an office and also over long distances, even around the globe.
Information Management is needed to cope with the amount of data that is processed by the people involved and to provide access to the data to the right people at the right time.
Sociology was already mentioned in the chapter about calendaring, and it is an important discipline: Everyday work is changed a lot by CSCW to make work more efficient. Sociologists should ensure that people are not overrun by the increased teamwork and the awareness of others about everything they are doing, but to encourage them to enrich the team with their individual ideas and visions and to find a way how the goals of the group can be reached together without losing members of the team.
Organisational theory helps the management to be able to change the structure of the company in a way that CSCW really can help to improve the effectiveness of the whole company. Sometimes teams will be composed in a different way than without CSCW. For example, it is more difficult to organise teams that change with every project. Another problem for organising a company is that now people can be involved in different teams at the same time, but the managers of the teams are based at different sites of the company. CSCW is based on distributed systems, because members of a group who use several personal computers want to share data and applications in order to work together. This chapter describes distributed systems and the underlying technologies and approaches.
Schlichter defines "a distributed system as one in which hardware and software components located at networked computers communicate and coordinate their actions mainly by passing messages" . This means that the members of a group use applications that are able to share information and can help each other to process the requests of the users. The software layers of distributed systems are shown in the following table :

applications, services

middleware

operating system

computer and network devices

A distributed application is an application that consists of different components. Each of these components has its own state and operations to change this state. Each of the components can run on a different machine, and they use the network for communication .
A definition for is also given by Schlichter:
"Middleware is defined as a layer of software whose purpose is to mask heterogeneity and to provide a convenient programming model to application programmers."
So it is a good help for the design and development of distributed applications because it already provides services for communication between the applications, access to distributed data and the processing of distributed transactions .
Middleware also provides , i.e. it masks all the difficult problems that come up with distributed systems. For example, location transparency deals with the physical storage location of objects in the distributed system. Location transparency means that the middleware gives a logical name for the object to the application programmer. He can easily use that name without thinking where the object is located at the moment. The current location of the object is resolved by the middleware, whenever the application accesses the object through the middleware . There are a lot of other types of transparency, which cannot all be covered here. One very often used architecture to realise communication between CSCW applications is the model. Some definitions should be given although the terms have already been used above. They have all been taken from .

A is a process that "initiates requests for service operations".
"A is a piece of software that provides a well-defined set of services."
"A is a subsystem that provides a particular service to a set of a priori unknown clients."

The clients are not known to the server before they request a service.
There is a difference between a client and a client machine, and even more between a server and a server machine: Clients normally run on client machines. Services can run on one or more server machines, i.e. a service itself can be distributed. Several servers can run on one server machine.
Client and server are often operated in operation: The client requests a service from the server, then it waits and depending on the implementation that can block the whole client application. When the server sends the reply with the result of the request back to the client, the client resumes.

The architecture introduces a new kind of application: This application is both a server and a client and is the interface between another client and another server. So there are requests sent from the client to the application in the middle, which acts as a server for this client, but itself requests services from the other server.
The example of the web applications can help to illustrate this architecture:

This figure was taken from .
The web browser is the client and relies on the web server. Additionally, applets can run inside the web browser that have their own application code, but also require services from the server. The web browser can either communicate with the web server using the or the Java functionality, which will be explained below.
The web server itself is not able to handle the requests of the clients on its own. So the web server requests services from an application server. This is a server that is able to e.g. access a database and process the required services, and then sends the result to the web server, which now again acts like a server and replies to the web browser.
That example shows how the web cannot only be used for information retrieval for which it was initially designed, but also to provide all kinds of services and therefore to support groupware applications as well. More information about web based groupware applications can be found in chapter 4.
There are a lot of application servers on the market, and it is not in the scope of this text to investigate application servers or their architectures. For further information about this topic, the reader is referred to Schlichter's description of the which basically is "a distributed application server environment" .

There is furthermore the model that consists of several processes or applications which can all communicate directly with each other. There is no process that has special functionality to coordinate the other processes. That means that they all have to contain their normal application code and additionally some code that provides the coordination . The advantage of this model is that no special server needs to be installed and configured. The disadvantages are bad scalability and difficult maintenance: Bad scalability means that with increasing numbers of participating applications, the traffic of exchanged messages will also increase rapidly, and that will cause poor performance. The maintenance of a huge number of applications is certainly much more expensive than the maintenance of only some servers. Also backup is easier when there is a more or less centralised solution. This chapter shows one aspect of middleware.
There are two ways how distributed applications can communicate with each other: Either message-based or using . Java's object-oriented version of RPCs is called .
The following table gives a good overview about which type of communication between distributed applications fits in which layer of the OSI model :

client-server model	layer 7 application layer
RPC	layer 6 presentation layer
message exchange, e.g. request-answer protocol	layer 5 session layer
transport protocols e.g. TCP/UDP	layer 4 transport layer

The request-answer protocol is described in . It provides bidirectional communication and uses timeouts and acknowledgements to detect and recover from message loss.

The advantage of RPCs is that it provides already all failure detection and correction, and normally works synchronously. So a programmer of a distributed application client just can use an RPC call to execute a remote procedure that is provided by a server, and the returned result can be used for further operations of the client. There is the problem that distributed applications need to know which component in the distributed system can offer which service. An RPC can only be started if the server is known that would be suitable. This problem is solved by the process of . There is static binding which means that the server address is hard-coded into the client application during its generation. Dynamic binding takes place immediately before an RPC is performed: The client needs to know a broker that can tell the current address of the server or acts as a mediator between client and server and just forwards the messages. The requirement is that the broker always needs to be informed if the server changes its address or service availability.
The is the object-oriented approach for dynamic component binding and provides the brokerage of objects instead of procedures and services . The goal is to use a standard language to form the RPC requests and replies. The currently most favoured language is the , because it provides well structured documents that are readable by all kinds of programs, only to mention some advantages.
XML-RPC is the easiest specification that provides RPC calls that are represented in XML documents and are transported via HTTP. For more information about XML-RPC see .
The is an extension of XML-RPC, and is a standard of the . It is described in .
The term stands for a new idea how companies can use computers. This topic does not directly affect the cooperative work of single users, but allows cooperation of different applications inside an enterprise. Hansen writes the goal of EAI is about "getting heterogeneous applications to work together in support of changing business processes" .
A characterisation of EAI comes from Ren : He states EAI has the "ability to integrate applications within the enterprise as well as across enterprises", and it provides "infrastructure adaptability", "support for multiple integration topologies" and the "power to handle complexity".
Buyens gives this definition of EAI: "EAI is the ongoing process of putting an infrastructure in place, so that a logical environment is created that allows business people to easily deploy new or changing business processes that rely on IT."
It always helps to understand a new technology or idea by looking back in history to realise what the problems are and what made this new idea necessary. Inmon has written a text to investigate the history of integration. He mainly focuses on data integration, which is only a part of EAI, but it helps to understand the overall background of EAI. In the early beginning of computer usage in companies, the first and only requirement was to "replicate manual procedures on the computer". So there was one application for each procedure. When better technologies came up, e.g. database technology, the existing applications where just extended, but they and their data remained seperated from each other. The problem is that there are actually data and procedures available in the companies' applications, but the applications cannot access each other's data or use the other's functionality.
An example could be a mainframe machine running programs written in Cobol, and now it is required to allow web access to the data managed by the established applications. That means you have to deal with different platforms and different standards.
Today, companies need to react very fast and implement solutions immediately. Competition has increased much more, because the Internet allows everyone to provide his solution to the whole world at once. The goal is to minimise the time of the development of a product until it is ready for the market. So it really helps the developers when they don't need to develop a whole application, but can combine the existing solutions and just add the required functionality.
So there are a lot of products and ideas on the market that try to bring different applications together to enable them to exchange information. They can be categorisied in different ways. One categorisation is described in the following chapter. The Hurwitz Group has defined the following types of integration. They are described by Gold-Bernstein . The level of abstraction increases in the following list of integration categories. "Platform integration" is at the lowest level of abstraction, then there is "data integration", "component integration", "application integration" and "process integration". "Business to business (B2B) integration" is at the highest level of abstraction.
The goal of "platform integration" is to bring together different architectures of "hardware, operating systems and application platforms" . Communication can be established with messaging, or .
"Data integration" provides gateways between different data stores, and also offers transformation from one data format to another.
"Component integration" deals with cooperation of applications concerning transactions and the use of the business logic represented in the procedures of only one component.
"Application integration" means that different applications can work with each other by using application adapters (also called connectors).
"Process Integration" stands for several applications that are involved in the same process. This is already a high level of abstraction, because the business manager can model workflows on this level. The workflows define how the applications have to work together and how e.g. an incoming order goes through several processes of different applications so that finally the product can be delivered.
"B2B integration" is integration not only inside the enterprise but between several companies that either work together as partners, suppliers or customers. This type of integration is also needed in mergers or acquisitions when two companies have to find the best way how to share existing data and procedures.

There are also other categorisations of integration, but this is not the place for further investigation into this topic. Kang gives a good overview over different methods of integration and their physical integration architectures. He compares "point-to-point" and "middleware" integration, and concludes, that point-to-point integration is not possible when there are too many nodes that need all to be connected with each other. Using middleware-based integration, all nodes are connected to one mediator in the middle and can communicate via this middleware.
He also describes the "message bus architecture", the "centralised architecture" and the "J2EE connector architecture" ().
Using a message bus architecture, all messages are multicasted, i.e. applications send messages to all other applications at the same time, and the addressed application reacts to the message. This causes a lot of traffic, and it is not secure because not only the addressed application can read the message.
The centralised architecture consists of one server that provides message filtering and message delivery to the connected applications, which need each an adaptor to being able to communicate with the server.
With the J2EE connector architecture, the server provides adapters for all connected applications, i.e. the adapters are not needed anymore in each application.
There are some good diagrams about these different architectures in . The goal of Pervasive Computing is to enable the user to access all his data anywhere and anytime from any device. The problem is that still not all people have devices that are always connected to the Internet. One reason for that is the sensitive data which is usually shared in a groupware environment. The use of a collaboration system is normally limited to the intranet for security constraints. Another reason for not every PDA having always access to the Internet is that it is too expensive at the moment.
Another challenge to groupware applications is that people want to have access to their groupware data from any device: They want to log in on every computer on the network and use their data, and then they also need to work with their PDA. When they are travelling, they use additionally a laptop, which also should provide at least the personal calendaring information. When they are not connected to the network, they still want to insert personal appointments, and wish to later copy them to the corporate groupware system. So there is the need for synchronisation between PDAs, the main server, and client programs on laptops. This chapter describes the standards that allow Email, shared Calendaring and synchronisation. The Calendaring chapter was divided into two chapters, because there are on the one hand the Internet calendaring standards and on the other hand a mix of other standards used for performing scheduling.
Some specifications are mentioned, but not fully paraphrased here. It is recommended to read the original specifications for further information.
The develops and announces the standards for the Internet. Each standard is defined in a . The goal of Computer Supported Cooperative Work is to support people in accomplishing their daily tasks. The question is how these persons can be represented in the system, and how they are identified by the system and by other users inside and outside the system.
Identification by the system is needed for the login process as well as for assigning the associated data to the correct user. An example for such associated data would be a mailbox that belongs to a specific person.
Identification by other users can be compared to the conventional visiting card. Other users like to have some public information about a person to being able to stay in contact and for further cooperation. In order to deal properly with users, a system needs a directory where the users are registered. This directory can be understood like a telephone directory that enables you to communicate with any of the huge number of people in your town. In contrast to such a global directory, an address book only contains the addresses of the people you met already or had some kind of contact with them.
Every server that manages several users needs any kind of directory.
A directory needs to implement an information model and to provide a protocol for querying and manipulating the information. A directory service is used by directory enabled applications that are able to use the information stored inside the directory. X.500 was developed by the , which is now known as the , and the . The first version of the standard was published in 1988, a second version was finished in 1992.

In his book "Understanding X.500 - The Directory" David W. Chadwick describes the history and the different parts and aspects of X.500. His book is the source for the following paragraph describing the X.500 standard.
There are the following parts of a X.500 directory model that should be mentioned:
The contains all the information stored in the directory. It consists of a set of entries which are instances of one or several object classes. Each object class is formed by several attributes with an attribute type and one or more attribute values. All the entries can be represented as the nodes of a . That means the entries stand in a hierarchical relation to each other.

The X.500 Directory model does not need to be a centralised system: It supports replication and distribution of information.
The is the component of the system that is run by the user. The user can insert his requests and retrieve the results.
The system itself is made up by several which are connected via the . They provide the to each other.
The DUA uses a protocol called to interact with the system. This protocol deals with the system as a black box. If a DSA cannot answer a request, a process called chaining is started: The DSA forwards the request to its connected DSAs. It waits for the results and finally returns a positive or negative answer.

DAP uses the network protocol stack, i.e. DAP provides a poor performance because every request and reply goes through all 7 layers of the OSI model. Because of that dependency on the whole OSI stack and the large functionality provided, the X.500 model can be called heavy weight. The first RFCs for LDAP were published in 1993. A good description of LDAP and other directory services can be found in the diploma thesis of Norbert Klasen . The following information is taken from his text.
In contrast to the heavy weight X.500 model of a directory, LDAP directly uses the TCP/IP stack. That means the layers above the transport layer are bypassed, which are the session and presentation layer. Some special functionality like chaining is also missing, but because of that the LDAP system is lighter. Instead of chaining, the server without useful information redirects the questioning user to the other known servers.
The goal of LDAP is to provide as much as possible the same functionality like X.500, but to be lighter. There are gateways to connect LDAP to X.500. The vCard, also called the Electronic Business Card, was invented by an initiative called Versit. Versit was founded by Apple, AT&T, IBM and Siemens. Since the end of 1996, the Internet Mail Consortium now has the control over vCard. The vCard specification describes the details of this standard.
vCard is also described in the RFC 2425 and RFC 2426 . The goal is to provide the users with several ways to give their details to other users. It should be possible to send the information with email (placing the vCard in a attachment), but also to send it via an infrared connection from one to another. The vCard cannot only hold information about a person but also about a resource. The vCard is related to the Directory Service by representing the details of an entry of the directory. The attempt was made to map the attributes of a vCard to the attributes described in the X.520/X.521 standards .
There are many address book applications that support the import and export of contact details via the vCard standard.
The vCard is a text file that uses the syntax specified by the MIME specification which is described in RFC 1521 . See more about encoding below.
This is an example of a vCard, created by the phpGroupWare address book:

BEGIN:VCARD
VERSION:2.1
X-PHPGROUPWARE-FILE-AS:phpGroupWare.org
N:Testsurname;Testfirstname;D.;Dr.
FN:Dr. Testfirstname D. Testsurname
BDAY:1970-01-01
URL:http://www.om.org
ORG:Operation Mobilisation
A.ADR;WORK:;;London Road 123;Carlisle;Cumbria;GB
LABEL;WORK;QUOTED-PRINTABLE:London Road 123=0D=0ACarlisle=0D=0ACumbria=0D=0AGB
END:VCARD

This chapter covers several standards concerning email delivery and reception and the format of a mail.
There are two standards which describe the email transporting process and the addressing format.
2 other standards provide access to received emails for users that are not always connected to the network.
Finally there is the email message and its standardised format itself. Some of the following information was extracted from .
Generally, there are three types of components: The , the and the . The MUA is that software that helps the user to send and to receive electronic mail. The Message Store keeps messages that have been delivered earlier already. Each MUA and each Message Store need to be connected to an MTA. The MTA is the program that is responsible for routing the messages to the correct destination. More than one MTA can be involved in an email delivery, when the message is routed through several networks. That means that the MTAs always need to be online on the network. The X.400 standards were published in cooperation by ISO and CCITT, now called ITU-T. That are several standards, all with a name in the format X.4xx. In 1984, the X.400 standards were described in a "Red Book" series. These standards can make use of the directory services provided by an X.500 implementation, which was mentioned earlier.
There are several protocols that define the communication in an X.400 Message Handling System. These protocols are just given simple names: P1 deals with message transfer between MTAs, P3 describes connections of both Message Store or MUA with the MTA, and P7 defines the rules of conversation between the Message Store and the MUA.
X.400 is a protocol that is based on the OSI model and belongs to layer 7, the application layer.
An X.400 address consists of values for the country code (C), administration domain name (ADMD), private domain name (PRDM), given name (G), and surname (S). An example address could look like this:

/C=UK/ADMD=OM/PRMD=ICT+Carlisle/G=Testfirstname/S=Testsurname

Some information in this paragraph originates from . The is an alternative to X.400. In contrast to the official X.400 standard, SMTP is only a "de facto" standard. But there is the 2821 , that is a recommendation how to implement SMTP compliant software.
SMTP is an Internet protocol, i.e. it is directly based on TCP/IP.
An SMTP address consists of a user name or alias, often used in a format like "firstname.surname". Then there is the @ ("at") character, and it is followed by the computer name that runs the mail server of the user. This computer name consists of the domain name and the toplevel domain name, which is assigned either concerning the type of organisation which the user is working with, or the country where the user lives. An example address could look like this:

Testfirstname.Testsurname@c.ict.om.org

c and ict are subdomains of the domain om.org. Because OM is a worldwide operating organisation, every department has its own subdomain, in this case the department is the International Coordination Team, and because it is based at two locations, the c stands for Carlisle.
The basic structure of SMTP defines an SMTP client (that is the MUA) and an SMTP server (that is the MTA). They can communicate with each other via SMTP commands and replies. The client also can send mail data to the server. The X.400 addressing format is quite complicated, but it can deal with all kinds of letters, and is therefore preferred by French speaking countries, e.g. Canada and France. SMTP addresses are easy to remember, but do not support special characters.
X.400 supports attachments, but loses the file names. SMTP needs the (see more about email encoding below) extensions for attachments.
SMTP is the most often used standard for electronic mail communication. Normally, the user is not always connected to the network, and is therefore not able to receive all of the emails that are addressed to him. The solution is that the mailbox of the user resides on the server, which usually also hosts the MTA. Now the user needs a way to be able to read the mails that are saved on the server.
Terry Gray describes the three types of operation how the user can access his email: In offline mode, the user accesses the Mail Transfer Agent from time to time and downloads the new received messages to his personal workstation. The downloaded emails are removed from the server. In online mode, the user reads the messages while he is online, the messages stay on the server, and he can manipulate the mails remotely. He has no copy of them on his machine. In disconnected mode, the user downloads the mails from the MTA, can manipulate them locally, and when he connects again to the MTA, the local and the remote mailbox are synchronised. Most of the following information is taken from the article written by Terry Gray . X.400 has its own protocol P7 to support the different operation modes, but if only Internet orientated protocols should be used, the following protocols apply.
The next paragraphs describe the two protocols POP3 and IMAP4 which both provide access to emails only. They assume the user uses SMTP for sending mails. Both use the Internet Protocol for transportation. POP3 is defined in RFC-1725 and IMAP4 is defined in RFC-1730 . The is originally a protocol that just supports offline operation. There is the attempt to provide online operation, by allowing the user to leave the messages on the server. But this is not a real online mode. One missing feature is the support of state information about an email, e.g. answered, read, etc. This is not supported by POP. Another problem is that there is no way to handle several remote folders, and you can't store a message on the server. The fully supports the offline operation model, but is is also designed for online / disconnected operation. It is capable to resynchronise an offline clients to the server. It supports remote message folders that can be modified like local folders. Some functions of IMAP: "IMAP4 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; permanently removing messages; setting and clearing flags; RFC 822 and MIME parsing; searching; and selective fetching of message attributes, texts, and portions thereof." The best usage of POP is the offline mode, because it was created for that type of operation.
If more functionality is required, IMAP is the best solution, because it supports all 3 operation modes. But it is more complicated, because it provides more functionality and possibilities to the user.
So it depends on the requirements of the users what protocol suites them best. Again, X.400 has its own rules and standards to encode mail messages and deal with attachments. But there is no place here to go into details about it, because the Internet standards are more commonly used.
The RFC defines the envelope and the contents of an email, also called the header fields and the message body. SMTP handles emails in this format. The following example shows some of the possible header fields in an email that is built according to the Internet Message Format.

From: Mary Smith &lt;mary@example.net&gt;
To: John Doe &lt;jdoe@machine.example&gt;
Reply-To: "Mary Smith: Personal Account" &lt;smith@home.example&gt;
Subject: Re: Saying Hello
Date: Fri, 21 Nov 1997 10:01:10 -0600
Message-ID: &lt;3456@example.net&gt;
In-Reply-To: &lt;1234@local.machine.example&gt;
References: &lt;1234@local.machine.example&gt;
This is a reply to your hello.

A description and categorisation of the header fields can be found in :
There are fields in the header that show who sent the message ("originator fields") and who is the receiver ("destination address fields").
The "identification fields" help to identify the current message and its related messages, e.g. the identification string of that message that this message is the reply to.
The "informational fields" provide information only important to the user, e.g. the "subject" field.
There is the possibility to resend a received mail to another person and make it look like it was sent by the original sender. This is realised with the "resent fields". These fields ensure that the receiver still knows not only the original sender but also who was the resender.
"Trace fields" are filled by SMTP, and they provide information about which way the message took across different servers to reach its destination.
There is a way to implement additional fields to build new standards based on the Internet Mail Format. These fields are called "optional fields". According to the Internet Mail Format, the content of an email is just "made up of characters in the US-ASCII range of 1 through 127" . The length of the lines is limited to 998 characters. This is enough for text content, when no special characters are used.
But sometimes there is the need to add attachments, e.g. multimedia files, images, or other files in binary format, that means files that use all 255 possible values of a character. Also some languages use special characters, that are beyond the 7-bit representation.
There are some ways for translating (or also called encoding) these files into text files, and then to decode them back. Some names of encoding types are "Base-64", "Quoted-Printable", "uu-encoding", and "BinHex".
Base-64 and Quoted-Printable will be described in more detail in the next chapter. The are defined in RFC 1521 . These extensions support multipart messages, i.e. a MIME encoded email can contain several files in all kind of formats. That enables MIME to be "a standard for the transfer of multimedia information via the Internet" .
The following table shows the recursive definition of an email message in MIME format:

message	header (includes SMTP header information)
	body is an entity	header of the entity (holds the content-type value)
		body of the entity is one of the types on the left	text
			multipart: several body parts of a given subtype, each of them is an entity
			application
			message
			image
			audio
			video

The iteration occurs on entity and message: The body of an entity can hold a message, and the multipart content can consist again of entities.
The "Content-Type" value of a header describes the content of the associated body, and the "Content-Transfer-Encoding" value gives the type of encoding of the body. MIME uses "quoted-printable" and "base64 encoding", or unmodified data in "7 bit", "8 bit" or "binary" format. "7 bit" stands for ASCII characters with short lines, "8 bit" data has short lines to be sent via SMTP, and binary data cannot be used with SMTP .
The idea of "Quoted-Printable" encoding is described in . It is mostly used for text that includes some special characters beyond the 7 bit range of value. The goal is to keep the text more or less readable by humans. Only special characters are modified according to a set of rules. That costs some bytes, because these modified characters must be different from the normal characters.
"Base-64" Content-Transfer-Encoding is not concerned about humans, and therefore encoded files "are consistently only about 33 percent larger than the unencoded data" . Basically, this encoding converts a file to a set of 6-bit characters, which means that there are 64 different values. Three bytes (8-bit) are converted to four 6-bit characters.
A "text" does not need to be an ASCII text, but can also be encoded. The charset parameter in the Content-Type field tells the character set of the text. The default is the US-ASCII character set, but also character sets for other languages with their special characters can be set here.
The binary data of some application ("application"), another email ("message"), or an "image", an "audio" or a "video" file can also be the content of an entity.
A message with several body parts ("multipart") is associated with a special subtype, which is one of "mixed", "alternative", "digest" or "parallel" .
"Mixed" means that there are entities with different types. If those entities do not have a header, they are just text files in US-ASCII encoding.
The subtype "alternative" allows the sender to include a document in several file formats. A "digest" is a set of email messages. "Parallel" is the same as "Mixed", but there is no significant order of the parts. The body parts are meant to be displayed at the same time.
The specification of the "Security Multiparts for MIME" defines two additional types for bodyparts of a multipart entity: "Multipart/Signed" and "Multipart/Encrypted". That allows to assure who sent a message and who is able to read it. The "Guide to Internet Calendaring" explains the relations between the different IETF RFCs that together define the standards for Internet calendaring.
There are some terms used by the Internet calendaring standards. They are described in , and the following information and quotations are taken from there.
Calendars are the "basic storage containers for calendaring information" of a person or resource. Calendars are made up of several components, which have properties that carry the information about the component.
A is an "entity (often a human) that accesses calendar information".
A is a data store which can hold several calendars and other calendaring information.
A Calendar Service is a program that allows several calendar users to access their calendar stores.
The is the application that runs on the user's machine and allows to manage the calendars provided by a calendar service or a local calendar store.
Calendar Access Rights define which users are allowed to perform reading or writing operations on what information on a given calendar.

The Internet calendaring standards are described in detail in the next chapters. gives a short overview of these standards: There is a definition of a language for describing calendar objects (iCalendar), an application protocol for using the language to perform scheduling (iTIP), and a description how to transport the messages via email (iMIP). At last, there is another protocol that allows to do calendaring with a calendar service in realtime (CAP).
There is an interesting comparison of the Internet calendaring standards and the Internet message standards in : iCalendar has the same goal as the Internet Message Format defined in , iTIP and iMIP can be compared with SMTP , and CAP is analogous to POP3 or IMAP .
New standards are in development and at least should be mentioned here: xCal allows to use the iCalendar language not only in the MIME environment but also with XML. SkiCal will extend the iCal language so that yellow-page directory listings can be enhanced to provide not only address information and descriptions of services, but also upcoming events and happenings. iCalendar is defined in the "Internet Calendaring and Scheduling Core Object Specification (iCalendar)" . iCalendar is a language to define the components of a calendar. It is based on the work of the vCalendar specification, that was written like the vCard specification by the Versit consortium, and is now controlled by the Internet Mail Consortium.
There are the following types of components that can fill a calendar: Event, To-Do, Journal entry, Free/Busy time information, Time Zone information, and Alarm.
Events, to-dos and journals can be recurring. Events and to-dos can contain one or several alarm components.
iCalendar defines several data types which are used to represent the properties of the components. Some of the data types will be explained with the examples.
For a complete understanding of all data types and all properties, the reader is referred to . An event can have a start and an end date. It can be related to to-do or journal components.
This is an example from :

BEGIN:VEVENT
UID:19970901T130000Z-123401@host.com
DTSTAMP:19970901T1300Z
DTSTART:19970903T163000Z
DTEND:19970903T190000Z
SUMMARY:Annual Employee Review
CLASS:PRIVATE
CATEGORIES:BUSINESS,HUMAN RESOURCES
END:VEVENT

There is an identification string UID that allows to build relations between components of a calendar. DTSTAMP gives a timestamp to show the date and time when this message describing the event was created. Another tag, LAST-MODIFIED, describes the time of the last change to the definition of this event. The CLASS value says whether the event is private, public or confidential.
For recurring events see the extra paragraph below.
An event also can be a reminder without consuming time, e.g. to mark a special anniversary. Then the tag TRANSP with the possible values OPAQUE and TRANSPARENT should be set to TRANSPARENT, so that it is not published as busy time . A to-do component represents something that has to be done, be finished, or be prepared at a given point in time. This deadline is given in the DUE property.
A to-do component can be related to other to-do or journal components.
The following example of an to-do item is taken from :

BEGIN:VTODO
UID:19970901T130000Z-123404@host.com
DTSTAMP:19970901T1300Z
DTSTART:19970415T133000Z
DUE:19970416T045959Z
SUMMARY:1996 Income Tax Preparation
CLASS:CONFIDENTIAL
CATEGORIES:FAMILY,FINANCE
PRIORITY:1
STATUS:NEEDS-ACTION
END:VTODO

There is a priority number assigned to a to-do so that several to-dos can be ordered. The status of a to-do can be one of the values "NEEDS-ACTION", "COMPLETED", "IN-PROGRESS", or "CANCELED". A journal is supposed to hold a descriptive text. It can be used to store information about past events or to write down just incoming information, e.g. minutes of a telephone call, or to prepare an event by adding some remarks to it.
Journals can be related to each other or to events or to-dos.
The following example shows a journal item, and it is taken from , but with a shorter description:

BEGIN:VJOURNAL
UID:19970901T130000Z-123405@host.com
DTSTAMP:19970901T1300Z
DTSTART;VALUE=DATE:19970317
SUMMARY:Staff meeting minutes
DESCRIPTION:Staff meeting: Participants include Joe\, Lisa
  and Bob. Aurora project plans were reviewed. There is currently
  no budget reserves for this project. Lisa will escalate to
  management. Next meeting on Tuesday.
END:VJOURNAL

There are special rules for formatting the content lines of iCalendar chunks, the maximum length of a line should be 75 octets. The process of inserting a carriage return, a line feed and a whitespace (either blank or a tabulator) is called "folding" and is described in . The result of folding can be seen in the example with the value of the DESCRIPTION property. In fact, it could be used for all iCalendar examples shown before, but it helps the human reader to write each property in a new line. A Free Busy Component can hold a request for free busy times of a specified time range, or it can be the response to that request, or it can be just a publication of free busy times.
This is an example for a request for free busy times from :

BEGIN:VFREEBUSY
ORGANIZER:MAILTO:jane_doe@host1.com
ATTENDEE:MAILTO:john_public@host2.com
DTSTART:19971015T050000Z
DTEND:19971016T050000Z
DTSTAMP:19970901T083000Z
END:VFREEBUSY

The ORGANIZER is the person that is asking the ATTENDEE for his free busy information in the time range given with DTSTART and DTEND. The response would also have the same ORGANIZER and ATTENDEE properties, but additionally some FREEBUSY properties and an URL where to retrieve the most current version of the free busy times.
This is an example of a publication of free busy times :

BEGIN:VFREEBUSY
ORGANIZER:jsmith@host.com
DTSTART:19980313T141711Z
DTEND:19980410T141711Z
FREEBUSY:19980314T233000Z/19980315T003000Z
FREEBUSY:19980316T153000Z/19980316T163000Z
FREEBUSY:19980318T030000Z/19980318T040000Z
URL:http://www.host.com/calendar/busytime/jsmith.ifb
END:VFREEBUSY

In this case, the ORGANIZER is the owner of the calender whose free busy time of the given time range is published. The time zone component is used to define time zones with their special arrangements about summer time (DAYLIGHT) and winter time (STANDARD) and their time difference from the .
This is not used very often, so the reader is just referred to to see an example. An alarm only appears as part of an event or to-do component and describes what action should be taken at which time to remind the user about the event or to-do.
This example is from

BEGIN:VALARM
TRIGGER;VALUE=DATE-TIME:19970317T133000Z
REPEAT:4
DURATION:PT15M
ACTION:AUDIO
ATTACH;FMTTYPE=audio/basic:ftp://host.com/pub/sounds/bell-01.aud
END:VALARM

The TRIGGER could also contain a relative time definition to the start or end of the associated component. It defines when the alarm should go off. It can be repeated several times with a given duration of silence in between. The ACTION can have one of the values "AUDIO", "DISPLAY", "EMAIL" or "PROCEDURE". According to the ACTION value, an attached audio file referenced by the ATTACH tag is played, or a message given in the DESCRIPTION field is displayed, or an email is sent, which is assembled from the DESCRIPTION as the body, the SUMMARY as the subject, and the ATTENDEE as the recipient. The PROCEDURE action executes the file that is referenced in the ATTACH tag, but this can be dangerous in an open system due to viruses or hacker attacks. There can be recurring events, to-dos and journals. Recurrences can also be used to define the summer and winter time of a time zone. There can be exceptions from recurrences, and for free busy times recurrences are split down to the single events.
The recurrence rule has a powerful syntax to produce any recurrence that could be required. It is described in all details in .
Normally a start date is given, and then there is a rule how often (COUNT) or till when (UNTIL) the event takes place with a given frequency (FREQ). Just some examples can be mentioned here: This example from defines that the event would recur for 10 days starting on the given start date:

DTSTART;TZID=US-Eastern:19970902T090000
RRULE:FREQ=DAILY;COUNT=10

Just one other example, from , shows an event that occurs on the first friday of each month for 10 times.

DTSTART;TZID=US-Eastern:19970905T090000
RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR

The is the scheduling protocol that allows to exchange messages to organise meetings. The messages hold events in iCalendar format. iTIP is not bound to a specific transport protocol. iTIP just defines the application protocol for scheduling meetings and working with Internet calendaring.
All the properties are already defined in iCalendar, but iTIP now gives them a meaning and prescribes semantics for performing Internet calendaring.
iTIP has rules for events, to-dos, journals and freebusy times, which are all components of a calendar item defined in iCalendar. In the following paragraphs the iTIP semantics only for events and freebusy will be explained in more detail. There are several types of messages that can be sent between Internet calendaring participants. The message types are: PUBLISH, REQUEST, REPLY, REFRESH, ADD, CANCEL, COUNTER and DECLINECOUNTER.
There are two roles defined by iTIP, Organiser and Attendee. Both of them are allowed to send some types of messages in specific situations. There are a lot of described situations, and this is not the right place to go through all of them.
The following table shows a simple example of organising a group event. The table was taken from .

Action	"Organiser"	"Attendee"
Initiate a meeting request	"A" sends a REQUEST message to "B", "C", and "D"
Accept the meeting request		"B" sends a REPLY message to "A" with its ATTENDEE "partstat" parameter set to "accepted"
Decline the meeting request		"C" sends a REPLY message to "A" with its ATTENDEE "partstat" parameter set to "declined"
Tentatively accept the meeting request		"D" sends a REPLY message to "A" with its ATTENDEE "partstat" parameter set to "tentative"
Confirm meeting status with attendees	"A" sends a REQUEST message to "B" and "D" with updated information.

Just to show one example of such a message (taken from ):

BEGIN:VCALENDAR
PRODID:-//ACME/DesktopCalendar//EN
METHOD:REQUEST
VERSION:2.0
BEGIN:VEVENT
ORGANIZER:Mailto:A@example.com
ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=BIG A:Mailto:A@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=B:Mailto:B@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=C:Mailto:C@example.com
ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=Hal:Mailto:D@example.com
ATTENDEE;RSVP=FALSE;TYPE=ROOM:conf_Big@example.com
ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:Mailto:E@example.com
DTSTAMP:19970611T190000Z
DTSTART:19970701T200000Z
DTEND:19970701T2000000Z
SUMMARY:Conference
UID:calsrv.example.com-873970198738777@example.com
SEQUENCE:0
STATUS:CONFIRMED
END:VEVENT
END:VCALENDAR

There are roles assigned to attendees. In this example, "A" is supposed to be the host of the meeting, "D" is not invited, but he should know about the meeting. If there is the RSVP (from French: répondez s'il vous plaît) parameter set to TRUE, then the organiser expects the attendee to send a reply. There is a room booked. E is not invited, but should know about the meeting.
Other more complicated situations are that an attendee proposes another date or time using a COUNTER message, and that the organiser replies either with a DECLINEDCOUNTER to reject it or sends a new REQUEST to all attendees.
The way to delegate an event is described in : The delegator sends a REPLY to the organiser, with his attendee property parameters filled with the status "delegated" and a value for "delegated-to" which holds the address of the delegate. There is also an additional attendee, the delegate, inserted in the reply, and his "delegated-from" parameter refers to the delegator. The delegator also sends a copy of the original REQUEST with the delegation information to the delegate. The delegate can react to this REQUEST as usual, i.e. decline, accept, or set to tentative.
Even situations how to replace an organiser are described in . This can be necessary for example when the organiser has left the company, and someone needs to be responsible to apply changes for the event.

Another problem addressed by iTIP is the sequencing of messages . Sequencing is important because every recipient of any message must know which one is the most current description of the event. The helps to see which message belongs to which event . One event and all the following messages concerning that event have the same UID, but different SEQUENCE numbers. The SEQUENCE number is incremented with every ADD and CANCEL, and also, when information of the event is changed, with PUBLISH and REQUEST, but not with a delegating request . A special case are recurring components that are split up: A specific instance of a recurring event is identified by the same UID as the recurring event, but has a special RECURRENCE-ID property which holds the specific date and time of the specific event . At last, the sequence of messages with the same identification can be discovered by comparing the time stamp which is given in DTSTAMP. Exchanging free busy times is only based on 3 methods : A calendar user can REQUEST free busy times of a given time range from another user, and this user can REPLY. Or a calendar user can just PUBLISH his free busy times without being asked for it.
Examples of a request and a reply dealing with free busy times were given already above. It just should be mentioned that it is possible to specify several attendees in a request in order to get replies from all required people. The is a transport protocol for Internet calendaring messages. It uses email standards for the transport. It is described in .
The messages are wrapped in MIME encoded emails. The "content-type" value is "text/calendar". This is a very basic approach, and it is recommended to use encryption and authentication e.g. with the "Security Multiparts for MIME" . The is still work in progress, and it is described in . CAP extends iTIP by some methods that are necessary for realtime operation on a calendar service. The iTIP workflows are not changed . CAP sends MIME encapsulated commands, and uses the as the transport and authentication protocol . BEEP is described in . It is based on TCP, and in contrast to the Internet mail protocols, it provides realtime operation.
There can be queries to search a calendar store (for examples see ), and all other necessary commands to administrate the calendar service and the remote calendar store.
This standard is still not ready, and some bits are missing. But it will become really important for standardised calendar servers. Because the Internet calendaring standards are not all confirmed yet and some solutions were created already before the existence of any Internet calendaring standard, there are some strange standards and ideas how to implement group calendaring.
The following solutions provide some kind of access to calendaring information in order to being able to organise a meeting. The is the Microsoft solution for applications which need to "exchange or store information in a particular format" . It consists of two parts, a messaging architecture and a client interface component . The messaging architecture defines the interactions between applications and messaging systems. The client interface component defines an interface for clients so that they can use the messaging systems through a standardised interface.
Furthermore, Microsoft uses a proprietary format for encoding MAPI messages into a serial data stream . It is called .
Service providers are pieces of software that can be accessed by an application through the standard client interface in order to use the messaging system that the service provider is able to use. The service provider translates the general MAPI requests und functions to the specific handling of the message store, the directory and the message transport. In the rest of this text, these service providers are called connectors, because some companies call their products like this and it illustrates the functionality of this kind of software.
For example, Outlook supports MAPI service providers. That means, that any company can develop a MAPI compatible service provider, and install it with Outlook. The service provider of this company would then use the messaging system of the company to manage all data that is processed with Outlook.
An idea often used with this approach is to save calendaring data in IMAP folders. This allows to save calendaring data wrapped in an email in one IMAP folder, and all content of one IMAP folder represents a persons calendar. The calendar server is responsible for the group calendaring, and it is able to read and modify the calendar data saved in the IMAP folders. The following approach only provides very poor group calendaring: It just allows to publish and subscribe free busy times. The disadvantage is that no details of the events that make the person busy is visible to anyone, and that everyone can only change his own free busy times. The advantage of the "only free busy times" approach is that no calendaring server is required.
Free busy times can be considered as shared information. You don't need a server, but just a shared workspace where you and your colleagues have write and read access to.
This shared workspace was first provided by a combination of the and the to access the directory with the free busy times on the server. The user saves his free busy times via FTP on the server whenever his calendar changes, and other users can subscribe to his free busy times and retrieve his free busy times via HTTP from the server. That helps them to organise a meeting because they can see whether the user would be available to attend the meeting or not.
FTP is not a suitable protocol concerning security constraints, because it has no encrypted password or data transmission, and a third person is able to listen to all traffic and can understand all data. HTTPS is the improved HTTP with extended security features. HTTP also provides the transfer of files in both directions, so people thought about extending HTTP with additional functionality so that it can be used for all kinds of distributed authoring and versioning. This new protocol, based on HTTP, is called . It is defined in as an "extension to the HTTP/1.1 protocol that allows clients to perform remote web content authoring operations". Data synchronisation can be defined as "the process of making two sets of data look identical" .
There is also a good definition of the term synchronisation protocol:
"A data synchronization protocol defines the workflow for communication during a data synchronization session when the mobile device is connected to the network. The protocol must support naming and identification of records, common protocol commands to synchronize local and network data, and it can support identification and resolution of synchronization conflicts."
At the moment there are a lot of different proprietary protocols for data synchronisation between PDAs, mobile phones, personal computers, and servers. That makes it hard to develop applications that process data that should be available on different devices: It needs to be ensured the application can communicate and synchronise with the whole number of different existing protocols. The creators of such a proprietary protocol are often the providers of an operating system that is designed for mobile devices. They also have the problem that they want their products to be usable with as much applications as possible. One step to encourage application developers to support their protocol is to provide a synchronisation software for several platforms and operating systems, which is able to use plugins from the application developers. These plugins are also called . They are able to access the application's data and to associate the correct data fields of the application with those of the mobile device's software.
But it is still an expensive task to provide a special conduit for each of a big number of existing products. In February 2000, the SyncML initiative was founded by some important companies that are involved in the market of wireless devices. SyncML stands for Synchronization Markup Language. The initiative aims to define a specification that allows devices to synchronise their data although they store it in different formats and are based on different software platforms. See more about technical details of this specification below.
In November 2000, already more than 500 companies from the same sector supported this initiative. A SyncML C Reference Toolkit was published under an open source licence in August 2002 . There were 99 SyncML compliant products in September 2002 . One problem was that many important companies joined this initiative, but Microsoft did not .

In June 2002 the was formed . Its members are the SyncML initiative and other initiatives which have their own synchronisation protocol standards. Besides other 200 companies, even Microsoft joined this alliance . The goal of this alliance is to create open standards and specifications for mobile devices that allow interoperability between devices from different providers and based on different platforms. Hopefully they will also create good standards for synchronisation. This chapter should just give a short introduction to the SyncML specifications.
They are designed to be platform independent and transport independent. The connection can be wired or wireless. Examples for supported transport protocols are HTTP, SMTP, the , and the . WSP belongs to the , and both protocols are supervised by the Open Mobile Alliance. OBEX was created by the and is a session protocol that is often used with Bluetooth.
There are two SyncML specifications: The SyncML Device Management specification helps e.g. to remotely update and configure the wireless devices in the company. In this text, the main focus is on the SyncML Data Synchronisation specification, which consists of two protocols and a for the XML compliant Synchronisation Markup Language. The two protocols are the SyncML Sync Protocol and the SyncML Representation Protocol. The Sync Protocol describes the ways data can be synchronised between a client and a server, while the Representation Protocol defines the semantics of the individual commands and their effects.

The Representation Protocol describes the SyncML Framework, which is shown in

. The Sync Protocol defines the behaviour and structure of the sync engine, the server agent, and the client agent, which are all outside the framework.
The SyncML Sync Protocol
There are 7 different types of synchronisation described in . The most common type is the , which only transfers the changed and new data items between the sync client and the sync server in both directions. The also synchronises in both directions, but transfers all data. The " from client only" only sends new data from the client to the server. There is also the reverse situation that the client just gets modified data from the server. Another type of synchronisation is a , which can be used either from the client or from the server only, and means that all old data is replaced with a complete set of data from the other device. The last type, the , gives the server the opportunity to ask the client for a synchronisation.
For all types of synchronisation, it is necessary that the involved devices know about the history of their data, i.e. the , and the history of synchronisations, which is represented with the . If a device is synchronised with several other devices, it needs to keep the records of history for each of the other devices .
also describes the sync initialisation that is required before every type of synchronisation. This initialisation both helps to detect the capabilities of each device and to authorise the access to the data that should be synchronised.
For more information and a good introduction to the SyncML Sync Protocol, see or . The main focus of this market study is the support of group calendaring. Synchronisation with an offline client and a PDA device is also taken in account.
Some assessment and comparison of the products can be based on common requirements, but the final ordering of the solutions is up to those who know the requirements of their own environment. This chapter describes the way used to analyse the existing solutions for groupware needs. At first there were some proposals from users who had come across some possible solutions. Other names of solutions could be found by searching on the Internet for "groupware". Another way to find further products was to read the documentation of a product, especially the references to competing products and how to import data. The discussion on the mailing lists of open source projects also gave the names of some products: People required that the coming open source product should have similar functionality to an existing product or should provide the import of data from that existing product. So while investigating the known solutions, some further solutions could be found. The best way to compare the different products is to collect a group of attributes based on a list of requirements. This list contains company specific requirements as well as common requirements. Each product should be investigated concerning these attributes, so to allow the comparison of each product with the others. Because the attributes are related to the companies specific requirements, it is possible to sort the found solutions using the attributes and the priority of the related requirement. So if a solution fails a requirement with the highest priority, it is marked as unsuitable. But the better a solution meets high priority requirements, it is more and more suitable. For the people who have to decide about the topic, there is also a short summary of the pros and cons, a conclusion based on that, and finally a standardised decision statement by which the products can be grouped. Some questions should be asked when investigating any kind of product:

Are there enough other users? What are their experiences?
Is the providing company stable enough to support the product over a long period of time?
Can the product be configured so that it meets the customer's specific requirements?

There are some points in assessing a product that are different for open source projects. There will be no agreement that will ensure support like a commercial product would provide. These are the topics that have to be investigated:

Looking back: How long does the project exist? What are the achievements of the project? Was there enough progress in relation to the time span the project exists?
Who is leading the project? Is it a single person or a team of leaders?
How many and what people are contributing to the project? Are there enough competent and committed people?
Are users supported by the open source community? How busy is the mailing list? Are there competent answers to problems of the users? How many users are using the product?
Does the license fit for the required use in the company?
Is there commercial support by other companies? How are those companies involved in the project? Are employees working with the open source community, or are they working on their own commercial extensions? (Some licenses allow that)
Looking ahead: Are there visions of new goals? Will future releases still meet the companies' specific requirements?

Answers to these questions can be found by visiting the projects' websites. Archives of the mailing lists provide information about past discussions. It also helps to look at the roadmap of the project to see plans for the future. If the project is hosted at a website that provides support for open software development, there is a short standardised description of the project. Some examples for such providers are:

Sourceforge.net (http://sourceforge.net) is a free service provided by VA Software.
Savannah (http://savannah.gnu.org) hosts both GNU and non-GNU free software projects, and belongs to the GNU Project.
BerliOS (http://www.berlios.de/index.php.en) is run by FOKUS, the Fraunhofer Institute for Open Communication Systems.

The following table shows the list of attributes that was collected for this work. It is influenced by the list of requirements. In many cases, the investigation of some attributes already made clear that the product would not be suitable for OM, because a high priority requirement was not met. For there was not too much time for the project, no further investigation was conducted in those products. That is the reason why not all products are investigated concerning all attributes.
The attributes and a short description for each of them are given in the following table:

name of attribute	short description
id	Identification string
category	association to a specific category (see possible values below)
short	if the category is not exactly describing the product, some more details can be given here
title	name of the product
version	the investigated version
Internet addresses	the website of the product; sometimes other Internet links to information concerning the product
download address	the Internet link to a webpage where a test or full version of the product is provided
documentation	a link to a webpage containing help for users and description of the product, or a description where to find documentation in the downloaded version
installation help	link to a webpage containing help for administrators, or a description where to find documentation in the downloaded version
installation hints	If the program was installed for testing on the OM Standard Linux Server, here is a short protocol of what had to be done and how arising problems could be solved.
demo version	link to an online demo version that allows testing the product without installing it; the public demo user login name and the password are also provided.
client	short description of the requirements of the client
server	short description of the requirements of the server part of the solution
licence	Is the product under an open source licence, or is it commercial?
costs	The prices of the product given on the webpage of the producer; What other costs of required products are necessary?
marketing statement	Just one sentence that is on the webpage of the producer and helps to see what goal the company has for this product.
calendar	The functionality of the calendar that belongs to the product is described here in more detail. Some products that got a special investigation have the subtopics "invitation", "private", "resource", and/or "repeating". These give information about how other people can be invited, if there is the possibility to create private appointments, how the booking of resources is integrated into the calendar, and how repeating appointments and meetings can be created.
email	If the product contains an email client, its functionality is described here.
data exchange	This is information about how the product allows synchronisation with PDAs and offline clients. Also export/import functionality with files is mentioned if available.
modules	A short enumeration of other modules besides calendaring and email, that are included in the product.
reliability of support	short description of the company or developers community, and information about the users community
pro	The main advantages of this product. They should be already mentioned in the investigation, but are summarised here.
contra	The main disadvantages of the product which are attributes of the program that don't fulfil a requirement.
conclusion	A short summary why and how the following decision was made
decision	The decision whether or not this product is suitable for OM. There are several defined decisions that group the products again, but now according to the requirements of OM. For the list of possible decisions see below.

This chapter shows how groupware applications can be assigned to categories. Different categories are formed, based on different points of view. In the end, a set of categories is given by which the investigated solutions can be grouped together. There are several approaches to provide groupware functionality:

peer-to-peer model: The clients communicate directly with each other e.g. via email. There is no central storage or processing of calendaring information. All data is stored locally. One example for this is Ximian Evolution.
free/busy server: This basically provides a central storage of calendaring data. There is no processing of data on the server. Outlook and Mozilla support this basic type of group calendaring.
client/server model: The user can use a client to connect to the server. The server can support clients running on different platforms. Not every client software also provides offline functionality, i.e. not all clients save the data locally.
multitier approach: A web interface is used to get access to the functionality provided by the calendaring server.

Some solutions provide a server that works with both a web interface and one or more clients, e.g. for several platforms. The products that include at least one client software, normally also provide a tool for PDA synchronisation. There are a lot of different types of licences under which a software can be developed and released. This text only uses the terms commercial and open source licences. Software with a commercial licence normally is not for free, and the main characteristic is that the sourcecode is not publicly available.
There are many different types of open source licences, but here this term is used for all software which is published for free and includes the source code.
Especially with the client/server approach it is possible to mix commercial solutions with open source projects. The following list is ordered by the degree of dependability on commercial software.

commercial client and commercial server (e.g. Exchange/Outlook, Lotus Domino/Notes, and lots more)
commercial client with commercial client connector tool and commercial server running on Linux (e.g. Outlook & Insight Connector & Insight Server)
open source client with commercial client connector tool and commercial server (e.g. Ximian Evolution & Ximian Connector & Exchange)
commercial client with commercial client connector tool and open source server running on Linux (e.g. Outlook & Insight Connector & Kolab)
open source client and open source server running on Linux (e.g. KDE-PIM & Kolab)

But also the solutions that provide a web interface can use different licence models:

webbased interface and commercial server running on Linux (e.g. BSCW)
webbased interface and open source server running on Linux (e.g. phpGroupWare, PHProjekt, moreGroupware)
A service provider can give allow users to create and access their data on a server that is on the Internet. The advantage is that there is no maintenance of a server, but information is carried out of the company and does not stay inside the intranet.

Most commercial solutions are sold on a per user basis, but some of them sell the individual client software. That makes the solution even more expensive if the user wants to access his data with both e.g. a Windows client and a PDA. Some of the commercial solutions have a quite long history and changed from proprietary standards to open standards. The products investigated in this diploma thesis can be assigned to the following categories:

Outlook/Linux: There is a Linux server that is able to provide Outlook with group calendaring
webbased & Outlook: A server running Linux that provides a webbased interface and allows Outlook either to use this server for group calendaring or to import and export calendaring data from and to that server
webbased: A Linux server just providing a webbased interface
webbased & client: A Linux server providing a webbased interface and some proprietary offline client
client: a client for group calendaring
sync: synchronisation tools, either for synchronisation between a server and Outlook or a server and PDAs

The following categories were formed because some products should be mentioned when talking about groupware, although they are not useful for the OM Standard Linux Server:

no calendar: groupware tools without group calendaring support
non Linux server: server requires e.g. Solaris or Windows operating system
outdated: These programs are not supported anymore.
service provider: These companies just provide group calendaring on their website.

This is a table about all the products that were investigated during this diploma thesis. For more details about each solution, please refer to the appendix, or see the following subchapters that mention some of the products in more detail.
This chapter gives a short description of some group calendaring supporting solutions.
The CAP protocol is not fully specified, so there is yet no basis for calendar servers to be built on the Internet standards. Hopefully, the soon future will bring Internet based calendaring in such a variety as there are Internet message servers and clients at the moment that are all capable of the same Internet protocols, e.g. POP3 and SMTP. This chapter gives an overview over the history of collaboration software and the existing integrated solutions that are delivered with both a server and a client.

Just to give an impression about the size and the shares of the collaboration market, here is a quotation from :
"In 2001, IBM led the $1.6 billion market with a 49 percent share of revenue, followed by Microsoft with 39 percent and Novell with 6 percent, according to market researcher IDC. Microsoft, however, ranked first in the number of customers. Of 210 million users worldwide last year, Microsoft captured 40 percent, followed by IBM with 35 percent and Novell with 16 percent."
The original articles from the market researchers are expensive, so it is not possible to provide the correct context of this figures. It seems that IBM/Lotus is more expensive, but enough companies are willing to pay for it anyway, so that in the end the revenue is bigger than that of Microsoft. But it seems that Microsoft will overtake IBM/Lotus by improving Exchange more and more and by having better user acceptance. For more information about this topic see .

IBM and Lotus have the longest experience in the collaboration market with their products Notes and Domino. Lotus introduced Lotus Notes in 1989 .
Microsoft published the first version of Exchange in 1996 . It replaced the Microsoft Mail Server. Exchange provides both a mail server and groupware functionality, e.g. shared folders that can contain e.g. email, calendars and documents. Outlook is the client for Exchange.
Novell Groupwise cannot be investigated here. It did not provide a Linux server, so it was not interesting for OM anyway.
There are also smaller companies that offer group calendaring software.
One example is MeetingMaker who sell their product with the same name. They are working in this area since 1990. They concentrate on just group calendaring and don't provide any other groupware functionality.
Another example is Fujitsu/Teamware with their product Teamware Office. This is a suite that provides several groupware applications, e.g. calendar, email, and forum. Lotus Domino and Notes were not installed during this diploma thesis, because it was obvious that these products would be too powerful for OM. They have so many features and provide all the applications that are already covered by the existing OM solution. They would replace the OM Standard Linux with its preconfigured applications, but it would take a lot of time to prepare Lotus Domino/Notes so that it is as easy to install and maintain as the existing solution.
But nevertheless, the Lotus products at least should be mentioned because they are widely used.
Lotus Notes is the "e-mail, calendaring, group scheduling, Web access and information management client" . Lotus Domino is the application server for it.
The approach of Lotus is to use a powerful database that is able to manage all kinds of entities. Examples for such entities are emails, appointments, documents, and much more. The database supports replication and therefore offline or disconnected operation is possible ( and . There is the possibility to extend Domino/Notes with customer applications. Domino can work together with the IBM Websphere Application Server to provide web services .
One point that needs to be mentioned is that Lotus was able to overcome the own proprietary email and directory standards and to implement Internet standards . This chapter focuses on Outlook, which is the client for Exchange. But this will show the abilities of Exchange as well.
Microsoft Outlook is very well known because Outlook Express, which is a restricted Outlook version with only email client functionality, is given away for free together with the Microsoft Internet Explorer. And Outlook belongs to the Microsoft Office which is used by many companies.
In earlier versions up to Microsoft Outlook 2000, there were 3 modes in which Outlook could be operated. In the current version, Microsoft Outlook 2002, all modes can be used simultaneously. That means one profile can contain several email account types at the same time.
In the "No Email Mode", Outlook just works as a standalone without any email functionality.
There is the "Internet Mail Only" mode, that allows using email services with POP3/IMAP/SMTP, and group Calendaring with the Internet Free/Busy feature. Internet Free/Busy uses the iCalendar standard to manage the free and the busy times of a person. The Internet Free/Busy times are saved and accessible from an HTTP server that runs the Frontpage extensions. These extensions are not only available for Microsoft's webserver, but also for the Apache webserver. For Outlook 2000, the Microsoft Web Publishing Wizard is required, but there is only a supported version for Windows NT 4.0 or Windows 98 .
Invitations are sent via email. That means that no realtime calendaring is used.
In the "Corporate Workgroup" mode Outlook has a connection to a groupware server, which normally is Microsoft Exchange. This cooperation is based on MAPI. But there are some other companies that offer a plugin program, which enables Outlook to communicate with another server than Exchange. Outlook provides offline folders, that can be synchronised with the associated folder on the server. A folder can contain emails, a calendar, notes, contacts and tasks (to-do). Permissions can be granted to other users on different levels, e.g. it is possible to permit a colleague to only add items but not to edit existing items. There are also public folders, which are folders without any write or read protection.
Outlook is able to import and export appointments in the iCalendar format, but the export works only with one appointment per file. So this is no real help for exporting all events of e.g. a week. Another type of import and export works with files in the text file format. The problem with this is that a lot of information, e.g. all the recurring events information, gets lost. A recurring event is replaced by one event per instance. There are no unique IDs assigned to the events, so it is difficult to avoid duplicated entries during synchronisation.
Every PDA supports synchronisation of calendar items with Outlook. That means that an Outlook conduit is delivered with the synchronisation software of the PDA. This chapter gives more details about some groupware clients. Only those clients are mentioned, that either seem to establish their own standards which are widely accepted or that are using the existing Internet standards and are expected to work with the coming Internet standards.
The Microsoft Outlook client was already investigated in detail. A connector software, e.g. Bynari Insight Connector, can be used to integrate Outlook with other servers than Exchange.
The open source community is working on some projects to provide free groupware servers and clients. On the client side, there is work in progress on Mozilla and OpenOffice.org. Mozilla is extended with a calendar application. The people developing OpenOffice.org want to integrate the Mozilla code into their groupware component. OpenOffice.org is the opensource version of StarOffice, which belongs to Sun.
These two projects, Mozilla and OpenOffice.org, are intended to run on both the Linux and the Windows operating systems. The problem is that there is no suitable free server yet available that would provide realtime calendaring.
Ximian Evolution is a client only to be used on Linux systems.
The KDE PIM application suite also requires Linux. There is a project called "Kroupware", they are developing the Kolab server (see below) and want to port the KDE PIM applications to Windows. The Mozilla project is based on the source code of the Netscape browser. In March 1998 this source code was released by Netscape under an open source license. People outside the company were invited to join the project, to improve the product and to develop the future releases. There are people payed by AOL/Netscape who only work on the Mozilla project, in parallel to the developers working on the Netscape browser releases. Mozilla technology can be used for every other project that fulfills the requirements of the Mozilla or Netscape Public License.
Some detailed information about this deal is described by Eric S. Raymond .
The current Netscape browsers (up from version 6.0) are based on Mozilla technology.
The Netscape Communicator 4.x contained a calendar component, but that was licensed from CS&T (Corporate Software Technologies International Inc., which is today known as Steltor and was taken over by Oracle). So the calendar component could not brought into the Mozilla project like e.g. the email client.
Because there is no open source Calendar server available, the calendar that is in development at the moment only supports exchange of calendar items via email and free/busy times using an FTP/HTTP or WebDAV/HTTPS server. The invitation is not yet integrated with the creation of appointments.
There is no PDA synchronisation available yet. But at least it appears on the requirements list of the Mozilla calendar. Ximian is the same company that founded the Gnome project. Ximian is opensource, and it is sometimes called the Outlook for Linux. It can be used together with the Microsoft Exchange server, but then a commercial connector from Ximian is required. It also can be used without any calendaring server, because it supports a peer-to-peer architecture for group calendaring. This is based on the Internet calendaring standards, by communicating via emails consisting of iCalendar messages. Free/Busy times can also be sent via email.
For more information about Ximian Evolution, see . The KDE PIM kit also provides some collaboration clients for the Linux users, e.g. an email client (KMail), and a calendaring client (KOrganizer). KPilot is a synchronisation tool for PDAs, and there is work in progress on Kitchensync.
Work on the integration of the several applications is going on, there is the Kaplan project and the temporary Kroupware project.
The Kroupware project was initiated by the German "Bundesamt für Sicherheit in der Informationstechnik" with the goal to find and/or develop an open source group calendaring server and the fitting client software . One step to the final solution is to provide a Linux client . This project was called Kroupware, but its name will either be replaced by a better name, or the project will be integrated into the existing KDE PIM tools.
Erfrakon also plans to port these applications to Windows in some time in the future . That could be possible by using the QT library and Cygwin for Windows.
The solution is not ready for group calendaring at the moment: Peer-to-peer operation is not possible, because the mail and the calendaring client are not integrated yet, and there is no server available. The Kolab server, also from Erfrakon, could fill this gap. It is described below. A lot of groupware servers also give the user the opportunity to access the groupware applications using a standard web browser.
The main advantage of using a web interface is the centralised installation, nothing has to be configured on the workstations. A suitable web browser is always available . But there is a problem with alarms or reminders: A web interface is only able to react, but cannot act on its own. A solution for that problem is the use of a Java applet or a routine in Javascript that can poll the server to ask if there is an upcoming event. Another disadvantage when using the solution inside an intranet is that the data is not available from the outside, which would be important e.g. when people are travelling. There are often solutions to synchronise a suitable client software, often Outlook, with the server that provides the web interface.
The big problem of the open source groupware solutions is that synchronisation with an offline client and a PDA device are not yet available. Most of those solutions are based on programs written in the language . That means there would be a problem if such a solution would be used in huge enterprises, because PHP was not designed to provide scalable applications, but to provide an easy programming environment for quick development . But that should really become a problem when a company with 200 workstations is using all applications of a PHP based groupware solution. In OM, only the calendaring application would be used, and a maximum of 50 workstations is accessing the groupware server at the same time.
A lot of calendar servers that have their own client or support Outlook as client, also provide web interfaces, e.g. Sun Calendar Server, Novell Groupwise, Samsung Contact and Suse Mail Server.
The open source solutions PHProjekt, phpGroupWare and moreGroupware are described below, TWIG and Tutos are not very different from them. phpGroupWare is an exception from the other open source solutions because it has a really good software architecture. phpGroupWare has the potential to become a real groupware server that does not only provide a web interface. This will be described later in more detail.
The BSCW system is developed by the German National Research Center for Information Technology (GMD). BSCW stands for "Basic Support for Cooperative Work". It is a commercial product, and provides web based group calendaring and other group supporting applications. The GMD also provides free accounts on their Internet server.
One other example of a commercial server in this category is ScheduleOnline. Its advantage is that it provides Outlook and PDA synchronisation, and the server runs on Linux, without requiring a special email server software. Those are the common problems with other commercial solutions, which fail in one or two of the mentioned topics. PHProjekt is in its third version, and it seems to be an established webbased groupware application. The leader of this project is Albrecht Günther. The problem is that there are no published goals to improve it more and more, and the ongoing work is not documented. For example, there is the requirement of synchronisation with PDAs posted on the website for months, but it seems that nobody is working on it. There is no import or export functionality of calendar items at all.
There is a product called phpOrgaSync that is able to synchronise Outlook and PHProjekt. It is freeware, that means it is available for free, but the sourcecode is not under an open source licence. So there is no chance to deal with bugs: If it was a commercial software, there would be a contractor that has to ensure the usability of his sold product by providing bug fixes. If it was open source software, there is the chance for everyone in the users community to find and eliminate the bug and publish the bugfix on the Internet. But with freeware, the user has no rights besides being allowed to use the software. This project has not yet reached the 1.0 release stage, but it is already a program that needs to be taken serious. It is led by a team of 5 people. That ensures that the project will be pushed forward even if not all members of the leading team are working on it. The problem with open source projects is, that a lot of the developers and the team leaders are only working on the project during their leisure time. That means if there is a hard time at work or the family requires more attention, the open source project which is just a hobby will be the first to be neglected. But the propability of the project being stopped is smaller when there are several people in the team, because then responsibility is split up, and others can push the project forward.
The phpGroupWare software has a clean design, which is necessary because the project claims to provide not only a web based groupware solution, but a groupware that will be usable also for other applications and in the future for other clients.
The phpGroupWare API is clearly divided from the applications, and supports any kind of groupware applications that can take advantage of the functionality provided by the API. Even inside the applications, the code concerning the user interface is clearly seperated from the business layer, and from the storage layer. This modularisation combined with XML RPC or SOAP functionality allows other programs in all kinds of programming languages to request services from the phpGroupWare server.
More information about the phpGroupWare API is given in chapter 5.
The goal is to port the phpGroupWare project to another language than PHP. Especially in environments where only calendaring services without a user interface are required, PHP does not provide the best scalability. This project is supported and led by a company called "Morelogs" who wanted to create their own webbased groupware solution. It is not finished yet. The advantage of an open source project being supported by a company is that there is money brought into the project, by giving people time to work on the project during their payed worktime. But the general problem with such a situation is that the communication between the developers inside the company must be public, so that other developers from the outside are able to participate in the work. The integrated solutions as well as the servers providing a web interface were already covered above. This chapter now shows servers that are aiming to simulate an Exchange server that is able to deal with Outlook. Hewlett-Packard developed a product called OpenMail, which included Outlook support and group calendaring. It was bought by Samsung, renamed to Samsung Contact, and is now maintained by them. Samsung is actually using the program in their own offices. The product consists of proprietary server parts and a special MAPI connector for Outlook. In July 2002, Oracle also published their plans of entering the collaboration market. They bought the company Steltor with their product CorporateTime which is a group calendaring solution. Oracle is now working on the Oracle Collaboration Suite which will be based on Oracle's application server and database server. The goal of Oracle is to support Outlook so that people don't need to change the client software they are used to. The open source community always has the goal to replace commercial products by free products that can be improved and be used by everyone. For there is no competition but cooperation between several open source projects, it makes sense to find standards so that the products can exchange data and provide functionality to each other.
One of the first solutions to configure Linux to work with Outlook and provide Email and Calendaring was developed by Kevin Erickson ( and ). He only used open source software. One disadvantage of his proposal was that he did not provide a MAPI connector tool, so he only could realise Free/Busy group calendaring and email server functionality.
Following Ericksons case study, some companies built their own packages of existing open source programs and published the scripts and installation routines either under an open source or commercial licence. The company Bynari had the goal to develop a MAPI connector that uses standards so that their Bynari Insight Server could provide also shared folders etc. to Outlook . This connector is called Bynari Insight Connector. It is a MAPI compliant software and enables Outlook to communicate with the server that provides the groupware functionality. The Bynari Insight Server is a commercial server that consists mainly of open source parts, e.g. the email server and directory server and so on. But the linking parts are not published. The company Neuberger & Hughes also follows the same idea with its product Bill Workgroup Server. The difference is that they develop the server under an open source licence, and only sell the MAPI connector software. Another project in this category is the Kolab project, they also want to build a Linux based server that provides Microsoft Outlook with the same services and functionality as the Microsoft Exchange server. The difference is that Kolab is open source and should also work with a KDE client. But the Kolab server also requires the commercial Bynari Insight Connector when Outlook should be used as client. The disadvantage of Kolab is that it still uses TNEF as the format for saving messages and calendar items, because the Bynari Insight Connector does not convert the data to a standard format, e.g. iCalendar. At least, TNEF is well documented and therefore it is possible to write Linux clients for the Kolab server. The Kroupware project group modified the existing KDE PIM applications to be able to use the Kolab server. It was already mentioned with some programs' descriptions how they support synchronisation, or if they use special tools to maintain several sets of data on several clients. The best solution would allow synchronisation of the server with the PDA and some kind of offline client, that also works in disconnected mode.
Generally speaking, there are three ways to synchronise PDAs:

Synchronisation of the PDA with the client program.
Synchronisation of the PDA directly with the calendar server
An extra synchronisation server manages all synchronisation between the different client tools of the user: PDA, web interface, and one or several workstation clients.

Microsoft and Palm have 2 different standards of synchronisation. Devices running Windows CE use the Microsoft ActiveSync technology, and Devices with Palm OS use the Palm HotSync technology. So it is required that a calendaring client or server provides one conduit for every PDA operating system, and it becomes even more complicated taking the other mobile devices, e.g. mobile phones, in consideration.
Palm provides Palm Network Hotsync that allows synchronisation with a remote server that can be accessed over a network .
Microsoft offers the Mobile Information Server , that will be integrated in the next major upgrade of Exchange .
There is also a number of synchronisation servers, but this is again no place for investigating them.

The reader is referred to to learn about the Sync4j project. This project provides frameworks to develop SyncML clients and servers, and is based on Java. This chapter now deals specifically with the needs of Operation Mobilisation. The current situation is investigated, the requirements of OM are collected, and the products discovered in the previous chapter are ordered again, now concerning the requirements of OM. 5 choices for suitable solutions are given, and in the end one of these options is investigated more, and a prototype of the modifications to this program is described. At the moment, OM are still working on standardising the use and the structure of the computer and network systems in their offices. Some procedures are not computer supported at all.
The OM Standard Linux Server, which is used by all offices except the ships, provides email functionality, access to the web, a backup system, shared diskspace on the server, and some other helpful services.
Sharing documents is possible by using the shared diskspace on the server. But there is no version control or log of modifications.
Mailing lists are mainly used globally, so a solution based on the OM Standard Linux Server is not possible, because the servers are not always connected to the Internet. At the moment, the free solution of an Internet mailing list provider is used.
There is a worldwide intranet for the whole organisation, and each office has its own local intranet as well. The local intranet is not standardised.
In the Carlisle office, the intranet provides a readable resource calendar, e.g. for laptops, mobile phones and other resources. The calendars of some important persons in the office are also available with read access. There are persons who are responsible to manage these calendars. There are also printouts of calendars for every month with the birthdays of the staff in that office and details for events during the month.
The offices on the ships use a Microsoft Windows server instead of the OM Standard Linux Server, and the people on the ships got very used to have Microsoft Exchange for scheduling. They don't want to switch to the OM Standard Linux Server because there is no group scheduling available at the moment. But it would be better for OM to have a centralised development team of the server system, and only one system administrator in each office. The goal is to have the same linux server in each office. That allows a standardised training of system administrators and helps the Carlisle Linux team to support them when there is trouble with the system. At the moment, the ships need their own specialists for the Microsoft solution, while the servers of the other offices can be maintained by normal system administrators without special development or adaption skills.
So both the ships and the Carlisle office have their own solutions for calendaring. But there is no OM standard for group calendaring, and offices without the necessary skilled staff don't have group calendaring at all. The list of requirements can be found in the appendix. The requirements were collected via email from the people in the offices that are responsible for installing and administrating the local computer network, and other developers working for OM. That is the origin of most of the requirements. Some other requirements came from the managers of the Linux team who are responsible for the development of the OM Standard Linux Server.
It turned out that some requirements did not belong to the task of providing OM with a groupware solution. The definition of this solution had to be made, and finally only a groupware calendar was left. All email concerning requirements were postponed, the only requirement to the calendaring solution was that it has to support the existing mail functionality of the OM Standard Linux Server. The requirement of a centralized email address book was already met by an LDAP solution.
The main requirements were long term reliability of the solution, and the price of it. For OM is a charity organisation that only exists from donations, they have to ensure that the given money is not wasted but used in a sensible way.
A clear requirement was that the solution had to be integrated in the OM Standard Linux Server. The requirement for the client side was to support Microsoft Windows because this is the OM standard operating system for the workstations. The products were ordered according to the requirements list. So products that did not support a Linux server or did not provide group calendaring at all were put to the end of the list.
There were the following categories by which all solutions were grouped:

suitable: This product fulfils the requirements of OM
could be suitable / depends on other solution: This product could be fine, but it requires another product which is not available yet. The two programs together would fulfil the OM requirements.
promising, but still under development: The product's requirements list would probably fit the OM requirements, but the work on it still is not finished. There are already non stable testversions. There is the hope that the products in this category soon will be ready for real use.
need to be considered concerning the costs: These products would fit the requirements of OM. The selling companies were asked for discounts, and OM have to decide if it makes sense for them to pay for one of these solutions.
even with discounts too expensive for OM: These products would fit the requirements of OM. They first were in the category "need to be considered concerning the costs", and after the next stage (asking for discounts) they joined this category. Even with discounts these products were still too expensive for the budget of OM.
experimental: The difference to the "promising" category is that these products are far away from a stable release, and it is unkown how and when they will be usable.
missing synchronisation support means that there is no way to synchronise with an offline client, and/or no way to synchronise with a PDA directly or with a client that can synchronise with a PDA.
outdated: The product is not available anymore.
not enough reliability of support: Either the developer community is too small, or the product is free but not under an open source licence
not suitable for OM: that means that either calendar functionality is missing, or the Linux server is not supported, or the Windows workstations are not supported.
too difficult to integrate with current OM solution: The products in this group provide all functionality that is expected from a mail and groupware server, and they would replace the OM Standard Linux Server. But then all the preconfiguration need to be developed again, so that the solution would have the same easy installation and maintenance than the OM Standard Linux Server. That was not an option.

This is the list of the same products listed in the end of chapter 4, but now the products are ordered by the decision which was met based on the requirements of OM. For more details about the solutions, please refer to the appendix.
There are several possibilities:
Option 1: phpGroupWare & AxisSync
At the moment, phpGroupware has no support for data exchange and synchronisation with an offline client. But in contrast to the other free web based solutions, it is not too hard to add new functionality to the program. There are already import and export functions for address book items. It seems to be one of the most promising projects that will have a future. So it is useful to invest some effort into the project.
The functionality that could be added and was prototyped for this diploma thesis is the import and export of calendaring data from and to files in the format, that can be imported and exported by Outlook as well.
A prototype for Palm synchronisation also exists with the tool AxisSync, but it is not stable yet. The export of calendaring data from phpGroupware to a Palm device is working already, but the other direction is still missing. But work is going on with the development of this tool, and in the end of October there was a new release.
The solution is not ready at the moment, but approximately in autumn 2003, this product will be the first choice of free web based group calendaring solutions. But the synchronisation with an offline client won't be very comfortable.
Option 2: Kolab
This server is free, but the Bynari Insight Connector need to be bought. But it provides the full Outlook functionality, and therefore also PDA synchronisation is available.
At the moment the Kolab server is in the testing and bug-fixing phase, so it is not ready yet. It should be stable in spring 2003, and it will provide a cheap but comfortable solution.
Option 3: Schedule Online
This product is commercial and provides web based calendaring with additional software for synchronisation with Outlook and PDAs.
It is expensive, and cannot provide the conveniences of a solution that fully integrates Outlook.
Option 4: Samsung Contact
This product is also commercial and expensive, but it provides both a web interface and full Outlook integration. The PDA synchronisation is provided by Outlook.
Option 5: Free Internet Calendaring server
The best solution in the future would be a free calendar server in combination with a free calendaring client that both support Internet calendaring. The calendar server could be an extension of the current phpGroupWare API, or a program based on a future version of the libical library, which is an implementation of the Internet calendaring standards. The client could be the Mozilla Calendar.
It is hard to estimate when this solution will be ready, because the Internet calendaring standards are not confirmed yet. But in 2004 there could already have been started a new era of calendaring with some standards based free calendaring servers and clients.

If there had been more time, it would have been interesting to investigate these products even more and to compare their functionality in more detail.
The Kolab server was not installed during this diploma thesis, because it was still in Alpha testing.
There was also no time for the installation of Schedule Online, but the functionality could be checked in the online demo.
The installation of Samsung Contact was successful, and Outlook could be used with all its features. There were problems with installing the web interface which is written in Perl, so that would need further investigation. It was also not fully tested if there could be problems with the email server of the OM Standard Linux Server.
phpGroupWare got more attention, because the code was very interesting. But also here, the functionality was not investigated in all detail. However, some information can be found in the appendix with the description of the solutions. This chapter describes the phpGroupWare project in more detail. A technical insight into phpGroupWare and its applications is given, by investigating the calendar application and explaining the prototype that was developed in this diploma thesis. phpGroupWare is organised in a 3 layer architecture. That means that the user interface, the business layer with the logic and the data storage are seperated from each other. That allows the phpGroupWare project to have the goal of becoming a groupware server that not only provides a web interface. There could be a specialised WAP interface that allows also clients with small screens, e.g. mobile phones, to make use of phpGroupWare. XML-RPCs or SOAP could be used by client applications to access the phpGroupWare server and request services from it.
There is the idea for the future to port the phpGroupWare project to a real application server and use XML for the representation of data and queries .

To understand the modularisation of phpGroupWare, it is helpful to investigate the structure of the directories and the names of the files in which the source code is represented:
In the root directory of a phpGroupWare installation, there is one directory for each application. Furthermore, there is a directory called "phpgwapi" which holds the classes that provide all necessary functionality for phpGroupWare to be a framework for the development of groupware applications. It provides interfaces to e.g. the formatting of data for specific browsers, the access of data in different databases, account management, file access, and much more. Just look in this directory and read through the different files.
There are several other special directories that don't just hold normal applications, e.g. xmlrpc, soap, syncml-server, and the two directories with the setup tool and the preferences application.
All other functionality of phpGroupWare is provided by several applications.
Each application has the following subfolders:

doc
help
- EN
- FI
- ...
inc
setup
templates
- default
- idsociety

The "doc" folder should provide some documentation for other developers, while "help" contains information for the users, with subdirectories for several languages.
The "inc" directory is the most important folder of an application, because the classes with the actual source code are placed here. There are different types of files, according to their different tasks. There are the classes that are responsible for the user interface, their name is in the form "class.uiAPPLICATION.inc.php", while "APPLICATION" stands for the name of the application or an important part of the application, that is coded in this file. The files with a name like "class.boAPPLICATION.inc.php" provide the procedures with the business logic, and bo stands for business objects. The "so" classes are responsible for the access to the data storage, which is normally the SQL database.
The "setup" directory holds all information for the installation and upgrade of the application. There are the language files with translations for all strings shown in the user interface of the application. The information how to create or upgrade the appropriate tables in the database is also provided in this directory. Initial data, e.g. public holidays for the selected country, can also be given here.
The "templates" folder contains one default template layout for the application. There should be one extra subdirectory for each available template that provides a different screen layout.

The calendar application has two additional subfolders in the "inc" directory, which are "import" and "export". These folders hold files for the import and export of calendaring information into and from the several file formats. The goal was to have at least synchronisation of phpGroupWare with Outlook, because that would enable people to synchronise their PDAs indirectly with phpGroupWare by using Outlook as mediator. There is the hope that the AxisSync tool earlier mentioned will become available and stable soon, that would make synchronisation with PDAs much more easier.
It would already be a little help to allow synchronisation with Outlook via CSV files.
The following diagram shows the normal composition of an application with its classes for the user interface, the business logic and the storage parts. Furthermore the modifications that were necessary to support CSV files can be seen in this diagram.

At the moment, the socalendar_ class is based on SQL storage.
The uiXport, boXport, import_conv and export_conv classes were added to create the prototype for the CSV support. The phpGroupWare address book application already provides CSV functionality, and so the names and the structure of the classes were taken from there. Also the algorithms for storing and loading CSV data with using a buffer were taken from there.
There was already a button for the import of iCalendar files. For a good design it would be necessary to change the structure of the classes, i.e. the functionality of the uiiCalendar class would be integrated into uiXport. But because there was only the goal to provide a prototype, the structure of the classes was not changed. The uiCalendar class displays the calendar application, and uses the colors and styles of the given theme and the layout of the current template. The uiCalendar class creates an business object, which is an instance of boCalendar. There is the function "uiCalendar.footer()" that needs to be modified so that beside the existing "import" button another button with the name "export" is displayed at the bottom of the calendar application. The template of this function is saved in the file "templates/default/footer.tpl". Another variable needs to be inserted there for the second button:

&lt;!-- BEGIN blank_row --&gt;
	&lt;td valign="top" width="10%"&gt;
	  {b_rowImport}
	&lt;/td&gt;
	&lt;td valign="top" width="10%"&gt;
	  {b_rowExport}
	&lt;/td&gt;
&lt;!-- END blank_row --&gt;

The button is inserted in the user interface in "uiCalendar.footer()" with these lines:

$var = Array(
	'submit_button'		=> lang('Submit'),
	'action_url_button'	=> $GLOBALS['phpgw']->link('/index.php','menuaction=calendar.uiXport.export'),
	'action_text_button'	=> lang('Export'),
	'action_confirm_button'	=> '',
	'action_extra_field'	=> ''
);
$this->output_template_array($p,'b_rowExport','form_button',$var);

If the button is clicked, the associated action ("menuaction") displays the user interface that is defined in the function "uiXport.export()" and shown in the following figure.

The user can choose from what period of time the calendar items should be exported. He can specify the start date and the end date of this period.
The export() function looks in the "calendar/inc/export" directory for any files, and expects that each of them holds a class called "export_conv". This idea helps to provide export functions for several file formats, e.g. different language versions of Outlook CSV files. The user selects the file format of the exported calendar data by selecting one of the options.
The class uiXport has an object of the class boXport, so when the user clicks the "Submit" button, the function "boXport.export()" is called. In boXport there is also an object of the class boCalendar, and the function "boCalendar.store_to_cache($period)" returns all calendar items in the given period in an array. Now for every event and every attribute of an event, the details have to be given to the current export_conv class. This class adds all information in the correct format to a buffer. In the end, "uiXport.export()" returns this buffer as a file to the browser of the user.
The following sequence diagram illustrates this process:

The prototype is able to export the following attributes of an event: The title or subject, the start and the end date, the name of the owner or organiser, the name of the participants, the description, the location, the priority and finally the information whether this event is private or not. The import functionality was not written in the uiXport class, because there was already an import button for iCalendar files on the front screen of the calendar. As already mentioned before, some functionality was inserted into the uiiCalendar class in order to change the existing classes as less as possible.
In the following screenshot the coexistence of the two possibilities of import is shown.

The way of using different import file formats is the same as with the export process described above. At the moment, an event on the same day and with the same title like the imported event is replaced with the imported event. For more about this topic see below.
The prototype imports the same fields of an event as it exports, but the owner is not yet resolved. The current user becomes the owner of the imported event. Participants are not imported at all at the moment. There are some topics that are not too difficult and would improve the import/export extension:
The export functionality should be extended by also exporting the names of the participants of a meeting and the category to which this meeting belongs to.
The classes involved in the user interface of the import functionality should be redesigned. Perhaps the people of the leading team of phpGroupWare should be asked first. The several file formats should be better integrated as well, e.g. should the icalendar format also appear in the drop down box with the Outlook CSV file formats.
At the moment the categories, the participants and the owner are not resolved in the import process. That should be realised, but it requires that Outlook uses only user names that have accounts in phpGroupWare.

There are also problems that limitate the import and export functionality with CSV files: One problem is that recurring events are split up by the CSV export and import because there is no way to save information about recurring events in the Outlook CSV file format. Another problem are the missing identification numbers of events in the Outlook CSV file format. That means that the import algorithm can only check for attributes, e.g. the subject, in order to find out if an event already exists in the calendar. But because the subject is not unique there can be different events with the same title. And if the subject is changed, there would be 2 events. A solution would be to rely on two or more attributes, e.g. start date and title, and if at least one of them is fitting to an existing event, this event is replaced by the imported event. But that can still always cause trouble. This is just a proposal how to integrate phpGroupWare into the OM Standard Linux Server. It should also show a bit of the XML-RPC functionality of phpGroupWare.
The OM Standard Linux Server provides an application based on text menus that helps system administrators to add and edit users. This application is called "sysadm", and it is programmed with Perl scripts. It would be useful, if the creation of a user in phpGroupWare could be integrated with the creation of a Linux user in "sysadm".
There is an XML-RPC implementation for Perl called Frontier::RPC which was written by Ken MacLeod. The "phpgwapi/doc/xmlrpc" directory also contains a file "perl.txt" which describes how to log into the phpGroupWare server with Frontier::RPC.
Only to get a quick overview of the opportunities of XML-RPC in phpGroupWare, the following example shows how to access phpGroupWare from an external PHP script, using the functions of "XML-RPC for PHP" from Edd Dumbill.
This function logs into the phpGroupWare server given in the "domain" variable, and uses the XML-RPC client given in the "client" variable. The client has already got the IP address of the server machine before the execution of the login function.

function login(&$client, $domain, $username, $password)
{
	$sessionid = -1;
	$kp3 = -1;
	$loginparams=new xmlrpcval(
			array("domain" => new xmlrpcval($domain),
				  "username" => new xmlrpcval($username),
				  "password" => new xmlrpcval($password)
			), "struct");
	$msg=new xmlrpcmsg("system.login", array($loginparams));
	$response = $client->send($msg);
	$value = $response->value();
	if (!$response->faultCode())
	{
		$value =  $value->scalarval();
		if ($value['sessionid'])
		{
			$sessionid = $value['sessionid']->scalarval();
		}
		if ($value['kp3'])
		{
			$kp3 = $value['kp3']->scalarval();
		}
		$client->setCredentials($sessionid, $kp3);
	}
	return $sessionid != -1;
}

"system.login" is the method which is called on the server, and the parameters for the username and password are also delivered.
This is the XML message that is sent by this function:

&lt;methodCall&gt;
&lt;methodName&gt;system.login&lt;/methodName&gt;
&lt;params&gt;
&lt;param&gt;
&lt;value&gt;&lt;struct&gt;
&lt;member&gt;&lt;name&gt;domain&lt;/name&gt;
&lt;value&gt;&lt;string&gt;localhost&lt;/string&gt;&lt;/value&gt;
&lt;/member&gt;
&lt;member&gt;&lt;name&gt;username&lt;/name&gt;
&lt;value&gt;&lt;string&gt;timop&lt;/string&gt;&lt;/value&gt;
&lt;/member&gt;
&lt;member&gt;&lt;name&gt;password&lt;/name&gt;
&lt;value&gt;&lt;string&gt;mypassword&lt;/string&gt;&lt;/value&gt;
&lt;/member&gt;
&lt;/struct&gt;&lt;/value&gt;
&lt;/param&gt;
&lt;/params&gt;
&lt;/methodCall&gt;

The answer looks like this:

&lt;methodResponse&gt;
&lt;params&gt;
&lt;param&gt;
&lt;value&gt;&lt;struct&gt;
&lt;member&gt;&lt;name&gt;domain&lt;/name&gt;
&lt;value&gt;&lt;string&gt;c.ict.om.org&lt;/string&gt;&lt;/value&gt;
&lt;/member&gt;
&lt;member&gt;&lt;name&gt;sessionid&lt;/name&gt;
&lt;value&gt;&lt;string&gt;16d7659129b54e81f282fc36ff839191&lt;/string&gt;&lt;/value&gt;
&lt;/member&gt;
&lt;member&gt;&lt;name&gt;kp3&lt;/name&gt;
&lt;value&gt;&lt;string&gt;3c125da178c4b53f360451252da03997&lt;/string&gt;&lt;/value&gt;
&lt;/member&gt;
&lt;/struct&gt;&lt;/value&gt;
&lt;/param&gt;
&lt;/params&gt;
&lt;/methodResponse&gt;

At the moment, the XML-RPC functionality is not added to every class. In the future, there should be a function called "list_methods" in every business object class. This function returns the names of all the available XML-RPC or SOAP methods.
For creating users using the XML-RPC interface, the file "admin/inc/class.boaccounts.inc.php" provides the function called "rpc_add_user". This function is not working yet. There was no time to find out the problem. But it should be possible to add a user with all the details, i.e. first name, last name, accountid, password, etc., as it is in the "boaccounts.add_user" function.
Just to finish this diploma thesis, this chapter gives a short conclusion about the current situation of the group calendaring market and shows the future functionality that will be required from groupware applications. In the end, there are some personal impressions about the past work for this diploma thesis. After investigating the existing and coming standards and the available solutions for group calendaring, the following conclusions can be made: At the moment, there are convenient and comfortable solutions, but they are commercial and not always based on open standards. Especially concerning the calendaring and synchronisation standards, this would even not be possible, because not all standards are finished and confirmed yet.
The open source community also provides several solutions, most of them are webbased. The huge advantages of a web based solution are the platform independence and the maintenance-free clients. But there is no free groupware server that is able to serve all three types of clients: a webbased interface, an offline client and PDAs. Own effort needs to be brought into each of these projects, and each company or organisation has to decide if this effort is worth the time and money that otherwise could have been spent on a commercial solution.
The other possibility, besides spending money or programming effort, is to wait for the coming times of free and standard based calendaring solutions and just take it when it is ready. A comparable situation is the huge amount of free email servers and clients that can be mixed with each other because they are based on Internet standards. One thing that should be considered is that it would be easier for the users if groupware functionality would be integrated in one user interface. It would help with learning how to use the system because there is not a different user interface for each application, and it would make communication via calendar, email, instant messaging or video conference even more normal.

The goal of integration is also pursued by the two companies that are the leaders in the collaboration market, IBM/Lotus and Microsoft. There are two texts which each describe the functionality expected of the coming releases: Cain writes about the future of Microsoft Exchange , and Olsen and Hawkins give an outlook to the next releases of IBM/Lotus Notes/Domino . Both companies mention the term which exactly means the integration of different applications that are delivered as components.
Microsoft plans that third parties can use Exchange services and content in their applications. Microsoft also will improve the performance in two areas: The required bandwidth should be reduced, which is an increasing problem because of the growth of email traffic and storage. Furthermore the storage on the server should be moved from the current solution of a special database to the SQL server.
Lotus Domino will move closer to the application server of IBM, which is called Websphere. The goal is to develop a new server program called NextGen which provides a J2EE platform and web services. It will coexist with Domino for a time, and finally replace it. Lotus Sametime will become a real-time collaboration server.
Another topic for the future is Pervasive Computing: Both servers will become more aware of pervasive devices and allow synchronisation and provide data access for PDAs, mobile phones, and other mobile devices. It seems that there are a lot of open source projects in progress, and it was interesting to watch the ongoing work and take a snapshot of the current situation. A better understanding of how open source projects work could be achieved by realising their problems and success. It was interesting to read the mailing lists and by that to be a passive part of some open source projects and the group of people that are formulating the Internet calendar standards.
It was good to have the chance to work without a lot of constraints on an own project, with the need to organise the time and work and to be finished on a fixed date.
A huge amount of information was collected during the work for this diploma thesis: The links to Internet articles, the details of the solutions, and the text of the diploma thesis itself needed to be managed. This was achieved by storing all the information in XML files. Some PHP scripts formatted the data and printed it to HTML documents. An Word macro was developed to help formatting the printable text of the diploma thesis. These scripts can be found on the enclosed CD-ROM, together with the online version of all information.