"Mechanism, not policy" is the mantra of the XwindowProtocol. Mechanism is in the XwindowServer, policy is up to the individual GuiToolkit''''''s and WindowManager''''''s. This fundamental guideline led to several architectural choices that are missing from most other graphics systems.
* Low-level drawing instead of widgets. This allows for choice among toolkits, look-and-feel, and skinning.
* Window management outside of the server. This allowed for much customization of and experimentation on desktop (and other) metaphors.
* Protocol instead of API.  The X window system defines its operations in terms of asynchronous stream protocols instead of function bindings.  This allows X applications to run on different machines than the graphics hardware (network transparency).  It also allows for multiple implementations of the XwindowServer.

It is worth noting that one of the policies that was left to the server, managing and rendering fonts, is now widely regarded as a design error.  This policy has now been migrated out of the server, via fontconfig, FreeType (Xft), and the Xrender extension.  Now the XwindowServer only manages the glyphs.  Fonts are managed and glyphs are rendered by client-side libraries.  This change in policy is responsible for X's ability to render anti-aliased fonts.
----
MechanismRichPolicyFree