4 ms·

People not familiar with X reading the above (which is correct) might miss that client/server is reversed from the way most people think about it. For X, the se

People not familiar with X reading the above (which is correct) might miss that client/server is reversed from the way most people think about it. For X, the server is the system where the display/keyboard/UI is physically attached and the client is the host (remote host for this discussion) where the application is actually running.

rhizome 9y ago
Like in DLNA, which repeatedly confuses-slash-aggravates me for no good reason.
- efreak 9y ago
  Except that DLNA has that third controller role that's usually taken over by either the client or the server, plus the confusion added by openhome servers with playlists (made even more confusing/annoying for me, since mine is provided by a fourth service/proxy, BubbleUPnP). Standard DLNA is easy to remember, however, as long as you know the terms--[file]server, renderer, and controller. It even uses http for the fileserver (not sure if that's part of the standard or not though)
JoshTriplett 9y ago
Ah, fair point. I've been around X for so long that I'd forgotten that being a point of confusion. I do think it makes sense in the sense that the "server" provides the resources and the client connects to them and uses them, but it definitely takes a bit of getting used to.
asveikau 9y ago
I don't know why this is confusing to people, at least if they understand sockets. The display server does listen(2). The application does connect(2). Why is that hard? Windows and Mac use similar terminology to "display server" too, but I guess those are proprietary components that few people look into...
- sjwright 9y ago
  I understand sockets and I understand how X works, and I think it's confusing and stupid. It places unnecessary emphasis on an implementation detail that is unimportant to the end user.
  - asveikau 9y ago
    Then say "app" or "program" instead of "x client" and nobody is harmed ... If people say "x client" it's usually in a more architectural, less colloquial context to begin with.
- DonHopkins 9y ago
  Both web client/server and X client/server nomenclature define what client and server mean in very specific (but opposite) technical ways, but I think both definitions limit how people think about what's really going on -- it's not so asymmetrical. Actually, I think of the client/server relationship as a higher level abstraction above the mechanics of the actual socket connection, which can go either way, or both, or many relationships at the same time in different directions and between different sites. All sites can offer any number of different asynchronous message based services to each other at all times. It shouldn't matter who was listening, who connected first or how they connected, just that all sites can send messages back and forth on the same channel. It could be UDP, multicast, WebRTC, distributed peer to peer, or a central message dispatcher. A (web client / X server) site with the display and GPU and mouse offers presentation and rendering and input services to different (web server / X client) sites, which themselves offer database and storage and computing services the other way, at the same time over the same channels.
  - asveikau 9y ago
    > Both web client/server and X client/server nomenclature define what client and server mean in very specific (but opposite) technical ways That's just false. A web server listen(2)s/accept(2)s. A web browser or other HTTP client connect(2)s. An X server listen(2)s/accept(2)s. An X client connect(2)s. In either case it would not make sense to invert this relationship. In both cases a server is an endpoint that serves its resources to multiple clients. Are people advocating conceptually that the graphics card connect to its programs, and not the program request access to it? That makes very little sense. Just like a web server would not proactively connect to its end user web browsers. The requests happen in the other direction.
IncRnd 9y ago
Yes. Server is used to mean serving graphics visually, the display server, not in the sense of remote processing.

rhizome 9y ago

Like in DLNA, which repeatedly confuses-slash-aggravates me for no good reason.

efreak 9y ago
Except that DLNA has that third controller role that's usually taken over by either the client or the server, plus the confusion added by openhome servers with playlists (made even more confusing/annoying for me, since mine is provided by a fourth service/proxy, BubbleUPnP). Standard DLNA is easy to remember, however, as long as you know the terms--[file]server, renderer, and controller. It even uses http for the fileserver (not sure if that's part of the standard or not though)

JoshTriplett 9y ago

Ah, fair point. I've been around X for so long that I'd forgotten that being a point of confusion. I do think it makes sense in the sense that the "server" provides the resources and the client connects to them and uses them, but it definitely takes a bit of getting used to.

asveikau 9y ago

I don't know why this is confusing to people, at least if they understand sockets. The display server does listen(2). The application does connect(2). Why is that hard? Windows and Mac use similar terminology to "display server" too, but I guess those are proprietary components that few people look into...

sjwright 9y ago
I understand sockets and I understand how X works, and I think it's confusing and stupid. It places unnecessary emphasis on an implementation detail that is unimportant to the end user.
- asveikau 9y ago
  Then say "app" or "program" instead of "x client" and nobody is harmed ... If people say "x client" it's usually in a more architectural, less colloquial context to begin with.
DonHopkins 9y ago
Both web client/server and X client/server nomenclature define what client and server mean in very specific (but opposite) technical ways, but I think both definitions limit how people think about what's really going on -- it's not so asymmetrical. Actually, I think of the client/server relationship as a higher level abstraction above the mechanics of the actual socket connection, which can go either way, or both, or many relationships at the same time in different directions and between different sites. All sites can offer any number of different asynchronous message based services to each other at all times. It shouldn't matter who was listening, who connected first or how they connected, just that all sites can send messages back and forth on the same channel. It could be UDP, multicast, WebRTC, distributed peer to peer, or a central message dispatcher. A (web client / X server) site with the display and GPU and mouse offers presentation and rendering and input services to different (web server / X client) sites, which themselves offer database and storage and computing services the other way, at the same time over the same channels.
- asveikau 9y ago
  > Both web client/server and X client/server nomenclature define what client and server mean in very specific (but opposite) technical ways That's just false. A web server listen(2)s/accept(2)s. A web browser or other HTTP client connect(2)s. An X server listen(2)s/accept(2)s. An X client connect(2)s. In either case it would not make sense to invert this relationship. In both cases a server is an endpoint that serves its resources to multiple clients. Are people advocating conceptually that the graphics card connect to its programs, and not the program request access to it? That makes very little sense. Just like a web server would not proactively connect to its end user web browsers. The requests happen in the other direction.

IncRnd 9y ago

Yes. Server is used to mean serving graphics visually, the display server, not in the sense of remote processing.