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.

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

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)

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

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...

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.

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.

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.

> 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.

I'm saying that client/server has a meaning that's independent of who initiates the connection, or what kind of connection it is.

For example, whether you weed dealer "Dave" calls you on the phone and tells you he can drop by if you're interested, or if you call "Dave" and ask him to drop by, "Dave" is still the server, and you're still the client.

You and your drug dealer are not computer programs operating over a socket. You are using a different definition of "client" to mean "purchaser". You may find that to be a useful description in that context but in a computer context it sounds like you are being intentionally vague.

I thought I was being intentionally pretty specific that client/server relationships can go both ways, at the same time, regardless of which side initiated the connection. Once you have a connection, no matter which side initiated it, or even if they both just randomly met in Linda tuple space like ships in the night, each side can offer services to and consume services from each other.