3 ms·

>They are at most as bad as any other key-value storage. No, a lot of other key value storage systems allow you to update individual rows and get notifications

>They are at most as bad as any other key-value storage. No, a lot of other key value storage systems allow you to update individual rows and get notifications when individual rows changed, kind of like you know, an actual database and not just an ini file. >You can update X resources without reprocessing "the whole thing" No, this is very wrong. What your example actually does is: - Read the entire global database from the X server, by fetching a property on the root window, which is just a string containing the entire database - Recreate the database in the client's memory - Merge in the one resource into the client's copy - Write the entire global database back to the X server again, by writing the root window property I encourage you to look at the source code to xrdb to verify this. I don't think I need to explain why this has problems and is actually bad, as is any other mechanisms in X that require clients to write to properties on the root window. >X resources are not locked to a single toolkit, they are locked to X11, but any application using any toolkit could use them. Sure. The problem here is that other toolkits will naturally disagree on resource names and will support resources that other toolkits don't, or that even conflict with resources defined by other toolkits. I think we know by now you can't just dump every setting from every app and toolkit into a key-value store of strings and expect it to work. >which was about applications using their own (or their toolkit's) INI parser instead of using what is provided by Windows. No not really. Even Microsoft suggests you don't use that function and instead use the registry because, despite all it faults, at least it correctly functions as a storage database. That function is also just bad because it requires reparsing the whole file if you want to read multiple keys.

badsectoracula 5y ago
> No, a lot of other key value storage systems allow you to update individual rows and get notifications when individual rows changed, kind of like you know, an actual database and not just an ini file. You refer to something different, not just some way to store configuration. > What your example actually does is That isn't really relevant though, that is an implementation detail, you do not access the root window property directly. It is a reason why it can be fragile but you'd have the same issue with some configuration library that read an entire file, made changes to key-value pairs and saved the file back - and then the same library was used at the same time by two different programs or instances of the same program. > Sure. The problem here is that other toolkits will naturally disagree on resource names and will support resources that other toolkits don't, or that even conflict with resources defined by other toolkits. Again, this isn't really an issue with X resources you cannot expect a resource meant for application A to apply to application B even if B could read it if it wanted. That different applications (and/or their toolkits) do not agree to common keys is a separate issue that isn't solved by using a different storage method. There isn't really a technical reason why applications can't agree to some shared keys (like, e.g. applications, toolkits and window managers agree to some common protocols to communicate with each other) regardless of their underlying toolkit. This is all a social aspect - the programmers who wrote those applications/toolkits decided to not support them. > No not really. Even Microsoft suggests you don't use that function and instead use the registry because, despite all it faults, at least it correctly functions as a storage database. Registry is something different, i explicitly mentioned this function in the context of parsing INI files. I mean, i do not think X resources is a great way to do configuration, but a major issue IMO is that it being locked to X11 when all popular toolkits wanted to also support other systems meant that they had to come up with their own approaches and nobody bothered to address (and maintain) the issues it has - so those issues remain around to this day. Same reason basically why Xaw despite being the closest to a default toolkit Xorg has still comes with the same primitive monochromatic look with usability that doesn't match to any common GUI toolkit released in the last 35 years.
- throwaway82652 5y ago
  >you do not access the root window property directly. Yes you actually do. This is literally what the program does. Please just look at the source code, we will go around in circles if you just go off my word. It's not just an implementation detail if that detail causes issues everywhere else. >but you'd have the same issue with some configuration library that read an entire file Yes you would, that's why file-based systems are also bad for storing configuration that needs to be accessed by multiple programs concurrently. They work fine if you have a program that ensures only one instance of itself is running, and you never edit the file with a text editor. >There isn't really a technical reason why applications can't agree to some shared keys (like, e.g. applications, toolkits and window managers agree to some common protocols to communicate with each other) regardless of their underlying toolkit. This is all a social aspect - the programmers who wrote those applications/toolkits decided to not support them. But this is wrong, other toolkits won't support resources that conflict with their own keys, they also won't implement shared keys that cause them issues or that are too much work to maintain compared to the benefit of them. We've seen this over and over when people propose standards for X11 based programs. It's not just a social issue. There is actual work that needs to be put into supporting these things everywhere and if you can't find people to do it then it won't happen. >Registry is something different, i explicitly mentioned this function in the context of parsing INI files. No we're talking about the same thing. The issue here is how do apps store and access configuration. The Xresources aren't magic, apps access those in the same way: by copying the whole database from the X server. So it's either that or you use another approach, like a registry. >that they had to come up with their own approaches and nobody bothered to address (and maintain) the issues it has Well many people have tried but none of the solutions stuck. Xaw is only considered a "default toolkit" because it was the first one, not because it was actually good at anything.
  - badsectoracula 5y ago
    > Yes you actually do. This is literally what the program does. I mean't you as a user using xrdb, not what xrdb does. Also applications are supposed to use Xrm functions, not messing with properties directly. That doesn't mean that an application can't do that, but unless it has a good reason to, it doesn't have to do that. > other toolkits won't support [..] they also won't implement [...] or that are too much work to maintain. We've seen this over and over when people propose standards for X11 based programs. It's not just a social issue. But that IS social issue - people agreeing that doing that is a good (or not) thing is a social issue, not a technical issue. There is nothing that technically prevents this, or even providing a more robust API to X resources with 100% fully backward compatibility (using, e.g. an X server extension that provides the configuration functionality with updates, etc, that then is exposed to root window in a serialized form). It is that historically nobody cared enough to do that, which is a social issue. > The issue here is how do apps store and access configuration The overall topic was but when i brought up that API in the comment above i was referring to INI parsing specifically. > Well many people have tried but none of the solutions stuck. There were tons of forks, mainly to change the looks, but none were adopted by XFree86 which is basically why they didn't stick. Some Linux distributions used them (e.g. i think Slackware to this day still comes with the Xaw3D) but by being ignored by the main X distribution, none of those went anywhere. > Xaw is only considered a "default toolkit" because it was the first one Well, it is also that because -in practice- it is the only one that is available in any Unix where there is Xorg (or a fork of it) running :-P.

badsectoracula 5y ago

> No, a lot of other key value storage systems allow you to update individual rows and get notifications when individual rows changed, kind of like you know, an actual database and not just an ini file. You refer to something different, not just some way to store configuration. > What your example actually does is That isn't really relevant though, that is an implementation detail, you do not access the root window property directly. It is a reason why it can be fragile but you'd have the same issue with some configuration library that read an entire file, made changes to key-value pairs and saved the file back - and then the same library was used at the same time by two different programs or instances of the same program. > Sure. The problem here is that other toolkits will naturally disagree on resource names and will support resources that other toolkits don't, or that even conflict with resources defined by other toolkits. Again, this isn't really an issue with X resources you cannot expect a resource meant for application A to apply to application B even if B could read it if it wanted. That different applications (and/or their toolkits) do not agree to common keys is a separate issue that isn't solved by using a different storage method. There isn't really a technical reason why applications can't agree to some shared keys (like, e.g. applications, toolkits and window managers agree to some common protocols to communicate with each other) regardless of their underlying toolkit. This is all a social aspect - the programmers who wrote those applications/toolkits decided to not support them. > No not really. Even Microsoft suggests you don't use that function and instead use the registry because, despite all it faults, at least it correctly functions as a storage database. Registry is something different, i explicitly mentioned this function in the context of parsing INI files. I mean, i do not think X resources is a great way to do configuration, but a major issue IMO is that it being locked to X11 when all popular toolkits wanted to also support other systems meant that they had to come up with their own approaches and nobody bothered to address (and maintain) the issues it has - so those issues remain around to this day. Same reason basically why Xaw despite being the closest to a default toolkit Xorg has still comes with the same primitive monochromatic look with usability that doesn't match to any common GUI toolkit released in the last 35 years.

throwaway82652 5y ago
>you do not access the root window property directly. Yes you actually do. This is literally what the program does. Please just look at the source code, we will go around in circles if you just go off my word. It's not just an implementation detail if that detail causes issues everywhere else. >but you'd have the same issue with some configuration library that read an entire file Yes you would, that's why file-based systems are also bad for storing configuration that needs to be accessed by multiple programs concurrently. They work fine if you have a program that ensures only one instance of itself is running, and you never edit the file with a text editor. >There isn't really a technical reason why applications can't agree to some shared keys (like, e.g. applications, toolkits and window managers agree to some common protocols to communicate with each other) regardless of their underlying toolkit. This is all a social aspect - the programmers who wrote those applications/toolkits decided to not support them. But this is wrong, other toolkits won't support resources that conflict with their own keys, they also won't implement shared keys that cause them issues or that are too much work to maintain compared to the benefit of them. We've seen this over and over when people propose standards for X11 based programs. It's not just a social issue. There is actual work that needs to be put into supporting these things everywhere and if you can't find people to do it then it won't happen. >Registry is something different, i explicitly mentioned this function in the context of parsing INI files. No we're talking about the same thing. The issue here is how do apps store and access configuration. The Xresources aren't magic, apps access those in the same way: by copying the whole database from the X server. So it's either that or you use another approach, like a registry. >that they had to come up with their own approaches and nobody bothered to address (and maintain) the issues it has Well many people have tried but none of the solutions stuck. Xaw is only considered a "default toolkit" because it was the first one, not because it was actually good at anything.
- badsectoracula 5y ago
  > Yes you actually do. This is literally what the program does. I mean't you as a user using xrdb, not what xrdb does. Also applications are supposed to use Xrm functions, not messing with properties directly. That doesn't mean that an application can't do that, but unless it has a good reason to, it doesn't have to do that. > other toolkits won't support [..] they also won't implement [...] or that are too much work to maintain. We've seen this over and over when people propose standards for X11 based programs. It's not just a social issue. But that IS social issue - people agreeing that doing that is a good (or not) thing is a social issue, not a technical issue. There is nothing that technically prevents this, or even providing a more robust API to X resources with 100% fully backward compatibility (using, e.g. an X server extension that provides the configuration functionality with updates, etc, that then is exposed to root window in a serialized form). It is that historically nobody cared enough to do that, which is a social issue. > The issue here is how do apps store and access configuration The overall topic was but when i brought up that API in the comment above i was referring to INI parsing specifically. > Well many people have tried but none of the solutions stuck. There were tons of forks, mainly to change the looks, but none were adopted by XFree86 which is basically why they didn't stick. Some Linux distributions used them (e.g. i think Slackware to this day still comes with the Xaw3D) but by being ignored by the main X distribution, none of those went anywhere. > Xaw is only considered a "default toolkit" because it was the first one Well, it is also that because -in practice- it is the only one that is available in any Unix where there is Xorg (or a fork of it) running :-P.