> If you added all those things as X extensions, it would essentially be the same thing as Wayland, because clients that wouldn't use them would still be broken, and every graphical program and toolkit would still be need to be updated to use them.

There's a massive difference between extending the X server and having each window manager implement all the trappings of an X server as a library. Namely:

* X remains the "narrow waist" for video/input multiplexing. GUI "policy" infrastructure -- window managers, panels, notification services, and so on -- remain separate programs, with separate maintainers, to be mixed and matched downstream as needed. Moreover, all these programs keep working.

* By remaining a separate X server program, we keep mechanism and policy cleanly separated. GUI "policy" infrastructure can't impose itself systemically on other GUI "policy" infrastructure, which is a good thing because all these GUI "policy" infrastructure authors tend to think their way is the best way and how dare anyone question it or resist it (see also GNOME). X keeps me and mine safe from their idiocy.

* The barrier-to-entry for creating new "policy" infrastructure remains low, since you can run these programs without coupling them to a particular compositor.

* Changes to X's rendering infrastructure get incrementally deployed. No change in any workflow is required; toolkits and programs opt-in to the new rendering infrastructure as they need to. Programs that don't opt-in keep working until the old code paths get dropped.

* Non-display services of X get preserved, like xprops, xinput, etc. All xclients keep working. If desired, these can be policed through a separate opt-in extension. Existing IPC conventions like ICCCM and NetWM keep working, so all the downstream tools that use them keep working.

> Your suggestions for dbus would work for some applications but would not really work for other things that a message bus handles like multicast, global message ordering, and resource accounting.

Nonsense.

You can multicast messages from one process to many processes via a UNIX domain socket trivially -- just send the damn message to each recipient! It's not like you're going to have 10 million clients, so copying the data isn't going to be that bad (and, the service endpoint can always throttle clients). But, sure, let's suppose the message you're trying to send is gigantic, and you do need to send it to lots of clients. You can just store it as a file (you're doing this anyway if the message is truly that big) and send each client a read-only file descriptor to go and consume it at their own pace. If you're using a file at least, all your clients will hit the same cached pages in the kernel, so you're no longer making N different copies of the data (the kernel will take care of implementing the right caching strategy for you). If you're streaming data, you could simply buffer it to a file and treat the file as a ring-buffer, and still hand out read-only file descriptors to it to downstream clients.

Global message ordering and message dependencies is also easily solved without dbus -- just implement an "ordering" service adapter. The adapter writes its own UDS to the place where its upstream services' UDSs live, and it takes care of marshaling requests and replies to and from the upstream services according to some ordering principle you require. For example, if you have a service for shutdown/suspend, and a service for logout, you could implement a small ordering adapter that prevents messages to shutdown/suspend from being delivered if the user is in the process of logging out. I'd imagine that for a DE, you could simply have a singleton ordering service adapter that determines what services get to be accessed under which circumstances (thereby cleanly separating the task of systems integration from the task of providing the individual service).

Resource accounting is similarly straightforward. Just like the "ordering" service adapter pattern, you can also create a "resource usage" service adapter pattern. For example, you can ensure that the volume increment or decrement requests to your sound daemon arrive at a fixed rate, no matter how many requests come in. As another example, if the service is streaming data, you can use a service adapter to monitor how quickly clients are consuming versus the service producing, and induce back-pressure on the service to hint that it should down-sample if clients are too slow.

Because everything is represented as files, I can do those last two things trivially with shell scripts. No need to take over the init process (cough systemd-logind cough), no need to implement a whole wire format and marshaling library and stub-compiler, no need to create language bindings, etc. Files, directories, named pipes, UNIX domain sockets, and a humble script to set desktop-wide policies on inter-service interactions are more than adequate. But noooooo, we had to build dbus and all of dbus's infrastructure.

I honestly believe the authors of dbus simply lack imagination. Like, we have all this wonderful battle-tested POSIX IPC infrastructure sitting around waiting to be used that they don't even have to maintain, and the kernel makes a fine I/O multiplexer and request broker. Why not use it to its fullest potential? It'll save time and effort, and you won't need any specialized SDKs or tooling to interact with services.

I don't want to say that I think the dbus authors are, well, stupid. If there's something that dbus does that well and truly cannot be done as described above, I'd love to know what it is, and why it justifies all the complexity of re-implementing POSIX IPC analogues in a bespoke system. But I've been writing software for over 20 years, and I've been around the block plenty of times, and this entire project smells like something someone would have written if they simply were not familiar with what their runtime environment could already offer them.

> Plus GNOME and KDE adopted dbus specifically so they could get away from having to pass around random sockets in folders everywhere.

So instead we should just implement worse-performing analogues of most of the POSIX IPC primitives in userspace and pass around service endpoints instead? Come on now.

> you're referring to kdbus, which was an alternate implementation not made by the original dbus developers, and is now a dead project and is not really a thing anymore. Please don't get those things confused.

Thanks for correcting me. I wouldn't want to hate on people for the wrong reasons ;)

------

Anyway, we've been going back and forth for a while. I'm convinced now that Wayland is just an instance of CADT and doesn't solve anything that couldn't have been solved with a less-glamorous but less-effort X extension. But whatever -- the X.org and fd.o developers are free to do whatever they want, etc. etc.

I actually like the X11 model, and wouldn't mind taking a crack at writing a Wayland compositor that simply back-ported all the non-graphical aspects of X as a Wayland extension. Then everything I'm using today could, ostensibly, keep working (and I don't have to care nearly as much what the fd.o folks do going forward).