Will@cup.portal.com (Will E Estes) (04/17/89)
I have no familiarity with X Windows, and I would like someone to explain to me the advantages of the X Windows architecture. As I understand it X Windows separates the code needed to display a window from the code that makes use of the window. I assume that messages are sent to a window manager. My questions are as follows: 1) on a single machine what are the advantages to multiple applications sending messages to a window manager? 2) over a network, why would a process on a remote CPU want to control a screen on my CPU? I have always heard that one of the advantages of the X Windows model is that it allows for distributed processing. However all the useful applications that I can think of (database, etc.) that involve distributed processing usually involve some sort of client-server relationship where the user interface functions are all handled on the user's machine and the database access is done on the server. Why is the X Windows method preferable to a more traditional client-server model, and what are some applications that would benefit from the new architecture. Forgive my naiveness in asking the above, but I am new to X Windows. Thanks, Will
rws@EXPO.LCS.MIT.EDU (Bob Scheifler) (04/17/89)
1) on a single machine what are the advantages to multiple applications
sending messages to a window manager?
In some ways it's the other way 'round: there are no significant disadvantages,
and it permits a network split (that's the big advantage). Explicit advantages
would have to be "compared with what?". It depends on a fair number of
factors.
2) over a network, why would a process on a remote CPU want to control
a screen on my CPU?
For all the same reasons that a local process would. For many applications,
I might prefer to run them on whatever machine will get the job done fastest.
If that happens to be a supercomputer at some remote site (or even one of my
staff's workstations :-), I'd still like to use the same windowing and graphics
as when running locally. Or it simply might not be possible to run the
application locally. As just one trivial example, some folks run xmh on
a remote machine, because their local machine doesn't support MH (for one
reason or another).
Why is the X Windows method preferable to a more traditional
client-server model,
X *is* based on a traditional client-server model. The "traditional" database
model is not "the" definition of a client-server relationship.klee@daisy.UUCP (Ken Lee) (04/18/89)
In article <17319@cup.portal.com> Will@cup.portal.com (Will E Estes) writes: >Why is the X Windows method preferable to a more traditional >client-server model The X Window System uses the traditional client-server model, with graphics/window operations being handled by the X server and application functionality being handled by the X client. -- Ken Lee Daisy Systems Corp., Interactive Graphics Tools Dept. Internet and Smail: klee@daisy.uucp uucp: uunet!daisy!klee
diamant@hpfclp.SDE.HP.COM (John Diamant) (04/25/89)
> 1) on a single machine what are the advantages to multiple applications > sending messages to a window manager? > > In some ways it's the other way 'round: there are no significant > disadvantages, and it permits a network split (that's the big advantage). > Explicit advantages would have to be "compared with what?". It depends on > a fair number of factors. I can't agree with this statement. There are significant advantages to the client-server model, but there are disadvantages, the largest being performance. Typical X Toolkit applications, for instance, generate incredible amounts of server traffic, and can be profiled as spending most of their time in I/O on the X socket. Now, it's true, much of this can be blamed on the Toolkit and not the X protocol, but not entirely. For instance, popping up transient windows is markedly slower under a window manager that uses SubstructureRedirect than one that doesn't. The reason for this is INHERENT in the X protocol: multiple server round-trips are required for a reparenting window manager. In contrast, a non client-server windowing system would be able to provide this negotiation much faster. I know your first objection to my statement would be that you can always use fast communication on the local machine via shared memory or such, but that really only provides significant benefits for large data transfers. The process switching and synchronization delays would still exist. Basically, X is a thin-wire protocol and that costs something. Don't get me wrong -- I think X is great and the client-server model makes a lot of sense for the benefits; I just can't agree with the statement that there aren't significant disadvantages too. John Diamant Software Engineering Systems Division Hewlett-Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant
rws@EXPO.LCS.MIT.EDU (04/27/89)
The reason for this is INHERENT in the X protocol: multiple server
round-trips are required for a reparenting window manager.
You just switched arguments entirely. The client/server model is independent
of the "policy" decision of where to place window manager functionality.
I know your first objection to my statement would be that you can always
use fast communication on the local machine via shared memory or such
Bingo.
but that really only provides significant benefits for large data transfers
Do you have (multiple) implementations and measurements to back up this
statement?
The process switching and synchronization delays would still exist.
Yes, but how are you proposing to get around them? If you want to support
multiple concurrent applications, some form of synchronization will still
exist. Since you haven't stated what your alternative architecture is, it's
hard to argue about whether or not process switching has gone away (or
instead been replaced with some other delay). And, in a properly designed
system, it's not clear that process switching should be a "significant"
disadvantage (else why are we all running multi-process systems :-).