Re: [TCLUG:12935] Remote X (client/server rant)

[Dave Sherohman <esper@usinternet.com>]

Eric Hillman said:
> No, they're in response to activity requests from programs that sit on the
> remote system, like telnetd or bash.

Yes, but, ultimately, on the systemic level, where are those requests
(generally) originating?  A user.

Of course, it could alternately be suggested that as I type this, my X
server, by receiving my keystrokes and passing them on to vi, is the piece of
software initiating the request.  When vi processes the keystrokes and sends
display updates back to the X server, it is doing so in response to requests
made by the X server itself - which makes vi the 'real' server.

This is no different from opening a control connection to a remote server
which then opens a data connection back to my machine.  My machine remains
the client and directs the activity, while the other remains the server,
responding to the local machine's requests, even though it initiated an
additional connection in the process of doing so.

> Typically, in order to initiate an X session on a remote machine I have to
> telnet to that machine and tell it to fire up rxvt or xpat2 or whatever.  I
> am running a telnet client, and am sending commands to a telnet server,
> which in turn fires up an X client, and tells it to connect to my X server.

At that level, yes.  But, in the overall picture, the request is coming from
the (user at the) local machine and being handled by the remote machine,
which then uses the local machine to display its results.

> The terminology is confusing at first, but from a networking/programming
> perspective, it's perfectly correct, and is vital to understanding how X
> works in the first place.

I believe that I have a decent understanding of how X works - and I haven't
seen anything in this discussion which contradicts that belief - I just
maintain that the terminology in that context is poorly-chosen, as it does a
very good job of appearing to contradict the meanings of the same words
('client' and 'server') as more broadly used.  IMO, the frequency with which
people, including some who should know better, use them incorrectly supports
the view that their usage was poorly-chosen.

> It helps if you think of it from the program's point of view.  "Client" does
> not, in any way, imply "human".

Yes and no.  Yes in that I'm aware of plenty of behind-the-scenes clients
(including a number that I've written), many of which act as servers also,
that operate without (direct) human oversight or intervention.  No in that,
when a UI is present, the UI is typically a major focus of activity and, most
commonly, is used to direct the show.  If requests are ultimately originating
from the UI then, in the overall picture, the UI is the client and everything
else is servicing the UI.

Your primary argument seems to be that, when servicing requests generated by
the UI, the various pieces of software have separate client-server
relationships among themselves, and I have no disagreement with that point.

The disagreement comes in from the assertion that the UI, though it is the
client at the systemic level, should be referred to as a server on the basis
of the lower-level internal workings of the system.

-- 
Geek Code 3.1:  GCS d- s+: a- C++ UL++$ P+>+++ L++>++++ E- W--(++) N+ o+ !K
w---$ O M- !V PS+ PE Y+ PGP t 5++ X+ R++ tv- b++ DI++++ D G e* h+ r++ y+