Consider now the centralized I/O agent-based implementation of a collaborative application. There is an unnecessary level of indirection here, the I/O agent does no more than forward requests to the local I/O package. Moreover, the master process and I/O managers are responsible for encoding the I/O calls as messages of some IPC mechanism. This indirection and use of an IPC mechanism would not be necessary if the application could use (directly or indirectly through a toolkit) an I/O package that provided a network interface, that is, allowed a remote application to directly invoke its functions, and if an application could concurrently interact with multiple I/O packages on different workstations.
The X window system [] is perhaps the first I/O package to offer such an interface. An X client can open connections to one or more X servers. Each X server runs on a workstation and allows its clients to perform window-based I/O on that workstation. It receives messages from X clients in the form of X requests and sends messages to them in the form of X events. An X request from a client asks the server to create a window, map it on the screen, draw text in it, or perform some other output task on the screen. An X event to a client informs the client about keyboard presses, mouse movements, and other input actions of the user. The X window system is ''almost'' portable in that it has been accepted by a large number of vendors. "Almost" because Microsoft decided not to adopt it.
Centralized Example: As before, we create a master process, which now interacts with the users of the collaborative application by directly communicating with the X servers managing their workstations. Instead of invoking I/O managers, they invoke special join processes whose sole job is to inform the master process about the identities of their X servers.
This implementation is certainly easier to code and more efficient than the centralized implementation we saw before. However, it is not without disadvantages. The application programmer must still implement a program used to join the session, which involves using some IPC mechanism to communicate with the master program.
More important, a larger amount of information is communicated from the master to the workstations, since, in comparison to high-level requests/events, low-level requests/events are typically larger in number and size. X was designed for high-speed local area networks, and is thus not ideal for wide-area, real-time collaboration.