In the previous section, we discused collaborative applications, that is, collaboration systems that provide end-users with some functionality to collaborate with each other. In this section, we will discuss collaborative infrastructures, that is, software systems that provide programmers with abstractions to implement collaborative applications.
Because of the diversity in collaborative applications, none of the collaborative infrastructures that have been developed so far is suitable for, or even capable of, implementing all of the collaborative applications we studied in the previous section. As a result, a large variety of infrastructures have been developed for implementing different kinds of collaborative applications. In fact, there may be more diversity in the collaborative infrastructures than in collaborative applications!
Therefore, when we study a collaborative infrastructure, we will look at the features of collaborative applications it can support, thereby evaluating its flexibility. Another criterion for evaluating an infrastructure is the automation it offers, which measures the amount of effort required to implement functions it ``supports''. We will distinguish between two basic ways to support some function: enabling, which simply allows the implementation of the function, and automating, which relieves programmers from implementing how the function is implementing, requiring them to only specify what they want. To understand the difference between these two forms of support, consider an assembly language, Pascal, and C. Pascal automates record management but does not enable interrupt handlers since it does not allow access to hardware registers. An assembly language enables both record management and interrupt handlers, while C automates record management and enables interrupt handlers. It is similarly important, in collaborative infrastructures, to provide a fine balance between automating and enabling. It is also important to offer space and time efficiency, another evaluation criterion we will use. Finally, we will look at the amount of reuse of existing systems supported by the infrastructure.
Dividing collaborative systems into applications and infrastructures is a simple but coarse classification scheme, since some systems have characteristics of both. Consider ClearBoard-2, which provides a shared whiteboard and video overlays. While the former is a specific application the latter is a general abstraction that can be used to provide face-to-face awareness in arbitrary shared applications. Similarly, the mail system can be considered an application since it directly interacts with the end user, and also an infrastructure since it provides a portable method for communicating information between arbitrary distributed applications. In general, a software system can be divided into may layers and a higher-level layer is an ''application'' for infrastructure layers below it. It is perhaps not surprising that kernel/OS researchers would regard most of the systems we discuss below as applications. They have been classified as infrastructures since each of them needs at least one layer above to interact with end-users. Later, we will look at their positions in a layered collaboration architecture.