One very interesting part of them is that they are stored on the X server, meaning you could have applications from different client machines all match the theme on your display, wherever that display happened to be.
But yeah, like the author said, it just didn’t really work out in practice since they’re just not terribly easy to use…
I think this was really what killed them as a concept. All of my documents are stored on the X client (or a file server accessed via the X client), my settings on the server. If I move between X servers, I can access all of my documents but not my settings. Places making good use of the remote X11 functionality would have a load of dumb X terminals, which ran X servers and nothing else, and a small number of beefy machines (connected to a file server if the small number was more than one) running applications. You’d go to a machine, type your password into XDM, and get an X session and run applications. These often didn’t have persistent storage, so if you changed X resource settings then they wouldn’t be preserved, and even if they were then they wouldn’t be propagated to the next terminal that you used. Well, they were, but only because xrdb synchronised them with a file in the user’s home directory.
Whether you’re using this kind of system or a more desktop-like model where the X clients and server and the filesystem all run on the same machine, your X applications all have access to a filesystem already. The filesystem is persistent and accessible to the application irrespective of the X server.
The only model in which you ran X11 applications from multiple computers that didn’t have access to your home directory. I never saw a deployment like that in the wild because a program that couldn’t access your home directory generally wasn’t very useful. The closest I came to this was running X11 apps on different servers that both had access to my home directory over NFS or forwarding a single app from another machine (which had access to a different one of my home directories).
X had a few attempts at trying to provide its own filesystem abstraction and none of them really made sense. I am sad that MAS never took off though. Remote X11 worked fine for the display, but X apps would generally just open /dev/dsp for audio and so remote audio didn’t work. 20 years later, PipeWire seems to be basically solving the same set of problems.
To clarify something: X applications (programs) looked up X resources from the server, but the server was not generally where you permanently stored them. Instead, you stored X resources in a flat file (often ~/.Xresources) and then your session setup scripts ran a command (xrdb) to load your resources into the X server. If you changed or set resources only in the X server, they’d be lost when you logged out or otherwise restarted the X server.
Of course this two step approach had problems, because if you changed .Xresources you had to remember to reload it into the server before it had any chance of taking effect.
Right, the problem is that going via the X server is useful only for applications that can connect to your X server, but can’t read ~/.Xresources. That’s a vanishingly small use case.
The OpenStep equivalent, NSUserDefaults, worked over the distributed objects mechanism and so could also be made network transparent if required and provided rich data types (basically the same set of things that you can store in JSON, though with proper integers) and added layering (system-wide defaults, overridden by user-wide settings, and then current-session ones) and a lightweight concurrency mechanism (you got a notification when someone else modified settings, though concurrent updates to the same key-value pair could be lost). That provided some real value on top of a local filesystem file (not least for things like the current locale, where every application receives a notification if the user changes it, even if they’ve changed it only for the current session and not persisted the change).
It’s just a database to store whatever you want in it. The reason it is in “decline” is only because applications stopped reading from it. The only application I use today where I would be hurt if that stopped, is XTerm.
I remember painstakingly crafting Xresources to get Netscape on FreeBSD to match my Black Box theme.
(I think it was Netscape? Might have been Mozilla at that point. This was 1997 or so.)
I always though that they had a bad name for what they were, and cried out ergonomics from an end-user perspective.