Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!think!paperboy!osf.org!dbrooks From: dbrooks@osf.org (David Brooks) Newsgroups: comp.sys.atari.st Subject: Re: Is there an X-Client for the ST? Message-ID: <1990Aug21.183714@osf.org> Date: 21 Aug 90 22:37:14 GMT References: <510010@hpbbi4.BBN.HP.COM> Sender: news@OSF.ORG Reply-To: dbrooks@osf.org (David Brooks) Organization: Open Software Foundation Lines: 35 In article <510010@hpbbi4.BBN.HP.COM>, stefan@hpbbi4.BBN.HP.COM (#Stefan Bachert) writes: (re X client/server) |> Anyway this name convention isn't intuive. |> In general a server offers a service. A client uses this services. |> (Think in fileservers, diskless cluster, ..) Here's how I try to get it across when I do X presentations. In the traditional client/server paradigm, the client is the program that has the actual application smarts. The server is just the dumb part. Think of a database server; it doesn't initiate any useful computing. It simply does what the client tells it to, request by request. Similarly with the X server. It's dumb; it's a slave. It accepts drawing requests from the client program and input events from the user and does what it's told, usually without any information about the purpose of the application being executed. Unfortunately our earlier experiences have led us to think of the client as closely identified with the human, and the server as over there somewhere in another room (or another country). That's why the X paradigm *feels* backwards; the server is always under the user's nose, and the client could well be on Mars (requiring a longer WM_TIMEOUT value :-). Having said all that, it usually takes a couple of months for new X people to get comfortable with the nomenclature; mistakes are usually forgiven... -- David Brooks dbrooks@osf.org Systems Engineering, OSF uunet!osf.org!dbrooks