To: Thomas A Watson who wrote (2349 ) 10/24/2000 11:16:14 AM From: E. Charters Respond to X may be flexible and partly extensible. i.e. code can travel to remote virtual machine space. That was how it was designed. But it is way too high bandwidth to function as an efficient, remote, extensible language in a production environment. Can you imagine a server running 32 X-processes for a bunch of clients? It would have to be a CRAY mark 2000 with a gigabit line. X hogs the resources and cripples all but the fastest machines. It eats memory like kids eat candy. Programs require scads of it. XCLOCK is a lousy two bit pop up that does nothing, AND eats 1.5 megs of ram. And what about colour maps? So clients don't care about servers? That is because the client is the server in X. the calling program in X that uses the resources is actually called the server . X has it backwards. And what about colour map flashing and crash and lock? X has plenty of that! What about cut and paste? Smooth? easy? Trouble free? uh-uh. What about simplicity of setup, profile controls, and customizability? OK, you can have lots of window managers. Neat, but hardly customizable. Why not one good WM?server that controls their resource allocation. Nothing else. This does not prevent interoperability, or remote operation, rather it aids it. Nothing but an X-knowledgeable machine will run another X program, unlike Java, which in part was intended to replace X. So if that is the case, then having the remote client understanding X, the bandwidth should be LOW not HIGH. But it is very high. Where is that at? It should take perhaps 4 commands in the calling program to open a window, not 4,000. The code should all be in the server. Why duplicate resources all over the network? Why give the client all the responsibilities of managing its own windows? Why does it have to know? Controlling windows is not the sames as building them, the same way that operating an elevator is not the same as hauling yourself up on a rope. X was built when one meg of memory was lots for a terminal to have. Today 128 megs is "normal" because all now is distributed computing or peer to peer. operating its own X server on the other end does all the work and puts up the window. To avoid confusion here we talk about true client programs and client machines. Remotely let's say a server runs a program when called by a remote client calling program. The client program should use its own local X-server GUI to operate a windowing system on its own machine. If another client program or machine starts a process, it should use the X-server running locally to locate more systems resources for windows by window managing code running in shared memory. Code should not be duplicated with each new client process on the local machine.control changes (buttons sliders, etc ...) with a point and click. Why super-complex rc files that you have to be a programmer who understands Chinese to change? Why not drag and drop and graphic cut and paste? and transparent text and easy font selection? And some of those GNU programs. Do this. Go into gimp and try to write in coloured text. Look for the manual that tells you how to select fonts and colours! Easy huh? So is killing whales with a pen knife from an inner tube.graphical or not by dragging and dropping them onto a command. Programmers who wanted to create a window would pick from a template and with 4 lines of C call the entire display window. GUI windows would have square pixels for easy scaling and image location and calculation of display co-ordinates. netlinux.dynip.com
