End-to-End Design in X Windows

David Manowitz

In the study of computer systems, concepts like modularity, abstraction, and layering are used as tools to control complexity and hide information from parts of the system that do not need it. As such, people may have a tendency to add layer upon layer in order to keep parts of a system isolated from each other. However, as is the case with most good things, too much of them can be bad. After a certain point, layers or abstractions begin to duplicate features of other parts and decrease performance. This idea is the basis for the end-to-end argument: functionality should be implemented in high-level layers or abstractions when possible so that lower levels truly provide basic services, without unnecessary redundancy. The X Window system provides two examples of this argument in its handling of obscured windows and input selection.

The X Window system is designed to support multiple overlapping windows, so it must be prepared to redraw windows that may be only partially visible. In the style of the end-to-end argument, the X approach is to let the applications handle such situations. In the paper by Scheifler and Gettys, two possible server-based approaches are considered: output display lists and offscreen buffers. With display lists, the server maintains a list of pending output operations to the obscured window. In this case, the problem emerges that the server may not know if an output to a window is nullified or modified by a subsequent request, so it must simply execute all these pending output requests, but this leads to long lists, so it may try to disregard some elements. These mechanisms can lead to possibly long refresh times when a window is raised or incorrect output, respectively. With offscreen buffers, the server maintains copies of obscured windows and displays them when they are no longer obscured. However, some graphics architectures make this scheme very hard to implement. Despite these problems, the designers of X Windows realized that server-based handling of obscured windows is unnecessary. Since applications often must have code to redisplay their entire window, and they maintain their own data structures, they can handle the obscured windows better than the server. By doing so, this functionality is pushed up from a low-level implementation on the server to one at the application-level.

Additionally, the X Window system uses the end-to-end approach in handling input requests. Input in X can come from different sources, such as the mouse or keyboard, and can be directed to any of the applications currently running. To deal with these complications, the server could perform some operations on the input, like filtering it by input type. It could then pass this input only to applications that are registered for that particular type of input. However, since the application is probably only looking for certain inputs, such as a particular keypress or mouse event, the extra work performed by the server would be extraneous. Thus, the server simply passes all inputs to the clients and lets them choose which inputs they are interested in. As in the case of obscured windows, the system is pushing back this functionality to a higher level that is better suited to handling it, in accordance with the end-to-end philosophy.

Thus, the X Window system exemplifies the end-to-end argument in at least two cases. Although these cases do not specifically involve moving functionality to a higher "layer" in the sense of a network protocol layer, they do move functionality from the server "layer" to the client "layer," as suggested by the end-to-end philosophy.