xfconf VS libxfce4util Resource Config Files for configuration

[Steve Dodier-Lazaro]

Woops, missing the first part of the novel I just wrote. This reads
*before* the previous email :D

Needless to say, don't take this email entirely to the first degree. I'm
ranting
like the moron I am, with no political correctness filter, about this
specific
topic but it should be stated I'm not targeting anyone in particular and
this
conversation can be had about pretty much every other type of software
we're using
and developing at Xfce.

> 'user tools and demands' - is there a demand for such integrated and
> extravagant settings maintenance though? (I know Matthew has responded a
> little later, will respond to that too). Are these demands from
> 'enterprise', which seems to be like a bloat cancer to anything it
> touches (e.g. its no longer a libre desktop under the control of the
> user, it is part of a larger system of control by sysadmins that want to
> have integrated settings, immediate updates, control over users and what
> they can set, etc etc)?

Yes, there is demand for having configuration files that are located at
predictable locations, and an interface that will look for said files in
a predictable order. There is also demand for whatever entity manages
this interface to automatically detect changes. For two reasons:

1. Yes, multiple apps share the same config item. Even though, often, there
will be one or few writers, there may be multiple readers for a setting. For
instance, multiple apps may want to know the user's locale, favourite font,
desktop resolution, wallpaper, GTK+ theme, a11y preferences, printer
preferences,
and so on. Considering only panel plugins, an app may have a good rationale
for
reading Power Manager settings (are we in power saving mode, or can I waste
CPU),
sound settings (e.g. some language training app or video chat app that
checks if
the volume is muted / very low in case the user doesn't respond to audio
stimuli),
clock / time, workspace names / switching behaviour / etc. Most plugins
directly
interface with or extend existing settings because those are relevant to
Desktop
UX and to Desktop apps.
2. Sharing / syncing configuration across multiple workstations,
automatically
updating configuration in an enterprise environment. I can't take seriously
the
idea that we don't want to support basic enterprise needs because it
"removes"
freedom from users. If someone is unhappy about having to obey social norms
in
any kind of group institutions, they might as well go live as an ermit. As
DE
developers it's not our place to discuss enterprise security / workstation
management policies, but to allow all the involved stakeholders to implement
whatever policies and configurations they need. As someone working in usable
security I can tell that most prohibitive enterprise policies are
counter-productive
and stupid, but I still need to let sysadmins deploy default config files
and
updates in a reliable way. There's also the case of PoS public devices
where the
session *must* be locked-down because all users are unauthenticated and
untrusted.

So yes, being able to accurately locate where the configuration file for an
app is
is necessary.



> There isn't a maintenance burden here, since I'm around, and if there
> was and I wasn't then you move to the question of whether it should be
> part of the official XFCE4 codebase (but thats a long way in the
future...).
>
> I'm not part of the team, so I can choose freely here.

I was making a more general comment. I personally prefer Qt over GTK+ but I
don't
write my Xfce code in Qt because it makes it easier for the rest of the Xfce
community to reuse it if I do the same as others.



> Yeah, I understand the idea of a central settings object, not objecting
> to that (just XML, anything dbus, having a superfluous always-running
> daemon just for configuration, etc etc).

You're reading "KISS" as "prefer the smaller / least feature-rich API". If
we
reasoned like this we might say as distributors that Awesome is KISSer than
Xfwm
and nano/vi KISSer than Mousepad. The whole point of Desktop Linux existing
is that
sometimes the additional "bloat" (aka basic usability features) makes our
lives
better. You're saying that you have an ethical consideration in not using
"bloat",
and by doing this you are reducing the utility of said "bloat" and ruining
the user
experience.

Let's consider two interfaces: the ultimate KISS iface and Xfconf. The
'you' used
below applies to any Desktop developer including me, not you specifically.

With the KISS iface:
- you read a file with open/read/close
- you need to guess where to load the config from, manually
- you parse it yourself with your own code embedded in your own software
- you manually poll for changes, and manually integrate your polling logic
with
  your existing UI event loop
- you manually bind UI properties to your file using custom code
- bindings are not atomic: either you reload the whole config or you write
  additional code to detect which properties changed and only update those
- you manually save your file when you change a property, and you need to
handle
  permissions and changes to standard XDG dirs in order to save them in the
right
  location

With Xfconf:
- you don't need to do file-parsing
- your config is always loaded from the best location, without you needing
to
  write manual code
- you have a strongly typed, foolproof API for reading and writing settings
- your change polling directly integrates in your UI's existing and
mandatory
  event loop
- you have one-line functions to bind UI properties to settings
- your bindings are atomic: Xfconf will only update you on the single
property
  that changed
- you no longer need to save config files, it's done automatically and at
the
  correct location no matter what

Key fact of software engineering: every developer, no matter how cool they
think
they are, introduces a constant amount of bugs per line of code written.
Let's
be generous (so that pedants don't whine at the number) and say it's
between 5 and
50 bugs per 1000 LoC. It doesn't matter. Less code = less bugs. Period. The
constant
holds relatively well regardless of language and code complexity, too.

Corollary: the less live code your system has, the less bugs your system
has.

Corollary: factorise code as much as you can. Less code on the system means
the
system has been kept simpler overall. Code duplication is way, way worse
than
code complexity.

Key fact of software engineering: the more diversely you test and use code,
the
more you detect bugs. Complete coverage of an API implies verifying that it
behaves
properly for all possible input ("proving" it works as expected). This
happens more
if the API is used by 20 different projects than by one project.

Corollary: reimplementing the same thing as your neighbour is really,
really stupid.
It leads to either everyone doing their own stuff and no standard existing,
aka no
predictable way existing for third-party hackers to hack how their apps
run, or it
leads to people just doing the same thing and apps having to be
individually updated
every time the standard evolves.

Corollary: every time two app developers have a common need, they should
implement
that in a shared library rather than shipping their custom code.

As long as app developers don't respect a strict cross-desktop standard for
config
files (among other things), we'll never have efficient and robust
implementations of
features such as sandboxed desktop sessions or migrating live apps across
workstations. These things might not matter to you as an individual
developer but
they do to other developers and to some users. And these complex features,
ironically
are available only if every follows standards to the letter.

If this argument doesn't convince you of the KISSness and superiority of
consistency
over personal developer ethics in a desktop, consider the case of fonts and
themes.
I don't like the way GTK+ works, ergo I will have my own way of parsing
theme files
and applying themes. And I will have my own way of having the user select a
font for
my system. Now, users with a11y issues need to go through the painful
process of
navigating through an interface that has a default theme with a font too
small, or
with too little contrast, for each and every of their apps instead of doing
it a
single time. And OEMs who want to ship distros that just work by default
for such
user bases need to repackage all the apps with all their custom
configuration files
because the developers are selfish, instead of having to change a single
theme
file / package.

Let's go back to KISS vs Xfconf. Surely the Xfconf features are unnecessary?

Automatic config location resolution: allows for system-wide
implementations of
multiple sessions or app profiles. Allows for multiple stakeholders
overwriting
config in a predictable order, regardless of the app's internal logic.
Allows for
users to easily, reliably migrate their configuration. By default. Without
the
automatic location resolution afforded by config librations like Xfconf, we
rely
on developers not being assholes and being up to date with standards in
order to
obtain reliable user experience. A quick "ls -la" will show you how many
assholes
there are out there in the wild who don't put their config files in the XDG
directory for user config files. I personally have software from 50-100
different
assholes (none of them Xfce <3). I stopped counting halfway through.

No manual file parsing: since you're ok with GKeyFile I'll assume we agree
that
not letting hundreds of individual devs play with fopen or open APIs is a
good
idea. From having supervised the programming of dozens of CS students, I can
guarantee you that you don't want to let most developers out in the wild do
something as basic as reading and parsing a simple RC or XML file.

XML vs binary vs RC: I prefer RC. XML has its own advantages since it
removes
potential ambiguity and limits the risk of those who refuse to use the
standardised
API and want to manually edit their config not escaping characters properly
when
dealing with complex config data. For instance if I named my workspace
"Work [email]"
and forgot to escape the brackets, how would a RC file parser react? Would
XfceRC
and GKeyFile behave the same way? Answer: NO. XfceRC and GKeyFile write and
read
string lists with a different syntax! They CANNOT be used interchangeably
for the
same config file! One of them will end lists with a semi-colon and the
other will
interpret this as the list ending with an empty element.

WHICH BRINGS ME TO THIS DESPERATE CRY: CAN WE PLEASE BURN XFCERC TO THE
GROUND AND
USE GKEYFILE LIKE RESPONSIBLE SOFTWARE DEVELOPERS!? Thanks *insert your
favourite
emojis here for added dramatic effect*

This kind of absolutely stupid situation is avoided by forcing everyone to
use the
same API and not allowing them to decide how that API parses and writes
files.

But I don't want a stupid daemon, I can poll the file myself: you
hypocrite. When
you do file polling, what you do is using a daemon called the Linux kernel
and an
API called the Linux IO system call interface. Software engineering fact:
reading
from IO is slower than reading from memory. The kernel has no standard
polling
interface because whether such interfaces could work depends on the
underlying
filesystem. This means you have no guarantee, when using polling iface Foo
or Bar,
and when you have 10 instances of your program running, that it will
efficiently
avoid duplicate effort. In fact, I'm willing to bet that most polling
ifaces will
require some thread regularly poking the file for changes and that at least
sometimes, the fact that the file has changed will not be cached and you
will
do more reads on the filesystem than strictly necessary. A daemon that
takes upon
itself to cache the config eliminates this problem. Changes to the file
require
a single act of polling, opening and reading and changes to the config from
one
of the daemon's clients requires no reloading of the file at all. Writes
occur
from a single process and so if multiple changes occur consecutively, the
kernel
will do a single actual write to the filesystem whenever the filesystem
type allows
that. You no longer need all competing config APIs / desktop devs with
their manual
code to drop the "O_DIRECT" flag on the config file to obtain performance.
And, is
your polling strategy optimal? How often does your polling library check
the file
for changes? How well does this integrate with your UI event loop? What is
the
upkeep of you polling your file (AND ALL OTHER POTENTIAL LOCATIONS FOR THE
CONFIG
FILE, see point above about locations) in 10 instances as opposed to your 10
processes receiving a single signal/message when a single daemon polls the
file /
transparently sends updates about settings which do not require file
re-reading?

File-based settings are just as good as daemon/IPC based ones: no. When
you're done
polling for changes and reloading the whole file in memory in each of your
instances,
you now need more custom code (aka more bugs) to decide which settings to
reload.
You then need to call your custom handler to update your settings UI and
your actual
configuration. If you had instead bound your UI and configuration to a
single Xfconf
key, all of this would have been done transparently. When you poll a file,
you also
need to decide what the crap it means when there is a mount event on the
file, when
it is renamed, etc, etc. Wanna bet that developers WILL make mistakes and
have
inconsistent behaviour across apps if we let them use GFileMonitor? If you
get an
unmount event on your configuration file on a FAT32 filesystem, what does
it mean?
For which filesystems is the mount event not valid, and just a result of the
awkward/non-compliant implementation of the filesystem? Etc, etc.

But I don't like GObject: good on you. You prefer to implement your own
thread,
your own routine logic and then integrate this with your GMainLoop (because
you
already use GTK+)? Have fun with that.

But I don't like DBus: DBus is the de-facto standard IPC API for Linux. The
reason
is simple: it's infinitely easier to construct strongly typed messages with
DBus
than it is with UNIX Domain Sockets or other IPC mechanisms. In fact, DBus
is
currently migrating to the Linux kernel. It will ultimately provide much
better
interfaces for security integration (both SELinux / namespaces) and spawning
multiple sessions than UDS do. UDS are unmanageable, all you can do is
translate
PIDs across PID namespaces and apart from that you have no security and
need to
implement custom intermediary daemons for each app/API that relies on a UDS
and
understand the custom semantics of the app to provide basic access control.
UDS
are not adapted for Desktop IPC. Various process polling files is as
unmanageable
by third-party security mechanisms as UDS or pipes or other non-standard,
untyped,
not necessarily well authenticated communication channels.



> Yes, its a 'nice to have' to have multiple instances of an application
> share configuration, but it is standard practice for this not to happen
> (because naturally settings are saved in one configuration file that
> should be read at the start, and written to later etc etc). Beyond this
> you can lock the configuration file and tell the user that other
> instances should be closed before you commit any changes.

It's not just nice, it's absolutely necessary. Will discuss this point
below in
response to your next email.


On 2 May 2016 at 19:52, Steve Dodier-Lazaro <sidnioulz at gmail.com> wrote:

> > Not sure what bugs will happen there, the point is it should be
> > 'anti-bug' since its only doing what is necessary and isn't touching
> > anything vaguely complicated.
>
> Less code = less bugs. The bugs per LoC constant.
>
> > Even in my limited experience as a user here, I've seen a serious
> > screwup with this extravagant configuration style - a mousepad config
> > change causing infinite dconf traffic spam resulting in serious CPU
> > whorage [0] - a problem that has absolutely nothing to do with changing
> > a simple configuration value (so 'acceptable bugs' here would be more
> > like, 'setting doesn't cause a change' or 'failed to update config file
> > due to read-only or disk failure').
>
> That kind of bug is fixed once and forever. It's also noticed faster if you
> have multiple apps sharing an API. If I copied your allegedly buggy config
> code for my own app and you later fixed a bug in it, I would remain unaware
> of the bug in my own app. Someone else would copy my buggy app's code
> before
> I get to fix the bug, and so on...
>
>
>
> > You would say, 'but there is more than one instance of the program!',
> > and I would say that its understood that you need to restart the program
> > to load a new configuration (or that updating configuration in both
> > programs will overwrite each other's changes) - thats just a bit of user
> > education.
>
> This is NOT an acceptable argument. As a rule of thumb, from a usability
> engineer,
> if you pronounce the words "user education" you're almost certainly doing
> something
> shitty. If I have 5-10 instances of gedit or Firefox (yes, I sometimes
> do!), all
> with various files / objects / websites loaded, with various states (some
> of which
> not serialisable, e.g. the undo history in gedit or the content of web
> forms in
> websites), I don't wanna have to close them all, then change my settings,
> then
> reopen them. It takes a crapload of time to do that, and it's error prone.
> If I
> forget to close one instance, I might lose the setting change. Worse yet,
> I might
> not be aware of that, leading to garden-path interaction breakdowns
> (
> http://methodenpool.uni-koeln.de/situierteslernen/PD%20of%20HCI%20-%20Suchman.htm
> )
> which might cost me later, when the app behaves in an unexpected way.
> Imagine for
> instance that I enabled the setting to warn me when I close an unsaved
> file/project,
> because the keyboard shortcut for closing all current projects is stupidly
> easy
> to hit in daily use (Firefox's Ctrl+Q next to Ctrl+W for instance). I was
> working
> on some project for an hour and accidentally hit the bad keyboard
> shortcut. I've
> lost my work and me resolving the situation after the fact does not repair
> the
> cost of the breakdown. There are good reasons why a setting must be
> immediately
> applied, or why I must be VERY RELIABLY assisted in whatever procedure
> must be
> followed for it to be applied. You need to tell people they have to
> restart the
> app, and make sure that they can do so without mistake, and without loss
> of current
> work. I doubt all individual desktop developers will do this properly, as
> opposed
> to just using the damn Xfconf API and making the problem disappear most of
> the time.
>
>
>
>
>
> > Lots of stuff can be programmed around, but its not worth the
> > cost of violating KISS (this is where the care bit comes in, presumably
> > most programmers that actually take the time to do this work don't care
> > enough about the bloat - 'its normal' - and therefore perpetuate this).
>
> This is not bloat at all, that's the whole point. If you implement half a
> correct
> settings infrastructure in your app, it'll be as complex as Xfconf is.
>
>
> > And you shouldn't have to put up with that situation being a possibility
> > at all. From my perspective, blaming it on yourself is overlooking the
> > absurd overthetopness of the situation. This is a big part of the bloat
> > badness - having to be a superstar programmer, having to know everything
> > from all over the place inorder to fix/implement a simple thing.
>
> The "superstar" programmer who uses Xfconf needs to write a few dozen
> lines of
> code in order to manage their settings. The programmer who does it all by
> themselves using their "not-superstar" knowledge of UNIX will write
> hundreds
> and hundreds of lines of low-level code, and have tons more error checking
> to
> do. From my experience, and from evidence found by software engineering
> researchers, it's easier to write a few dozens high-level lines with a
> really
> basic APIs than hundreds of lines of system code. If the API is good, that
> is.
>
>
> > It just sounds like feature bloat - implementing stuff without a serious
> > need, and discounting the difficulty/downsides of implementing it when
> > 'justifying' the feature.
>
> The bloat is when you have complexity written 50 times by 50 different
> developers,
> each of which tested in the wild by a single app, rather than something
> written
> 1 time by 1 developer, used 50 times by 50 different developers who
> therefore
> test it in 50 different ways. Don't implement custom code for settings if
> you
> can avoid. Xfconf is the least verbose option available to Xfce
> developers, ergo
> use Xfconf.
>
>
> > Yeah I lack a word to encompass the 'badness' involved. The 'software
> > ethics' stuff from the FSF comes closest to the idea. A recognition that
> > a lot of stuff used is overthetop/inappropriate/'bad', and by
> > perpetuating it, it takes its toll on resource use, control over the
> > code, ability to understand the code used etc.
>
> Xfconf is opensource. All the stuff it uses is opensource. It's better
> implemented
> than what all joint Desktop app developers can come up with overall if
> they all
> do their crap in their corner. It's more consistent. It requires less code
> loading
> overall as it's a shared library. It simplifies code and reduces bugs.
> Anyone can
> see what it does, how it does it, and fork it if we decide to become evil
> and
> change Xfconf to spy on users or cause cancer or whatever. Xfconf is not
> Mono.
> It's not a STD. It's just good software architecture.
>
>
> Now. I don't care if it's Xfconf or GSettings or Dconf or the new conf
> system that
> a bored software engineer wrote in between two sessions of making Internet
> memes
> about goats. As long as there's a single one, that is consistent and
> provides *all*
> the features that are required for optimal usability, performance and
> manageability. So let's choose one and bury the rest please. The whole
> "FOSS is
> free therefore I refuse to compromise" attitude is nefarious to any FOSS
> community
> in the long run. I hate GTK+ but I'm happy to read and write GTK+ code for
> Xfce,
> time provided. Because it helps the community if I suck it up. I believe
> the same
> should apply for settings handling, error reporting, UI design patterns
> and so on.
>



-- 
Steve Dodier-Lazaro
PhD Student
University College London
Free Software Developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.xfce.org/pipermail/xfce4-dev/attachments/20160502/54eddb4c/attachment-0001.html>