xfconf VS libxfce4util Resource Config Files for configuration

[OmegaPhil]

On 11/05/16 23:34, Steve Dodier-Lazaro wrote:
>> Thanks for your detailed responses, I've had a look around your site etc
>> but I can't see a donation email address etc?
> 
> I am curious why this idea came up :D I don't need donations for just
> annoying
> people on the mailing list :-)

Because at least I have some solid reasons for xfconf, DBus etc (which
saves me from having to gain the experience, which I probably wouldn't
get anyway as I avoid them altogether), and potentially I can bug you in
the future for counterpoints against stuff I come across.


>> In general: I'm coming from the standpoint of implementing a minimal
>> amount of functionality around a core problem that is to be solved - the
>> aim isn't to solve all problems or everyone's problem. In your emails
>> you talk a lot about the bad consequences of the alternative to using
>> shared libraries for solving (from my perspective) non-core problems -
>> I'm saying they aren't in the scope of the program and therefore aren't
>> to be solved (changing a program's underlying configuration store and
>> expecting it to update as appropriate, running more than one instance
>> and expecting configuration to be shared, etc). The use cases you
>> describe (loads of IDEs, Firefox instances, sandboxing, application
>> migration etc) sound very much like unusual edge cases that would be
>> rejected (or relegated to a separate optional removable
>> layer/implementation), with KISS.
> 
> Yes, you're right. Reasoning about what you need from an individual
> perspective
> differs from reasoning about it from a global perspective. This problem
> exists
> in design, in urbanism, in systems engineering, and so on... When there are
> multiple stakeholders involve with similar, yet slightly different needs,
> savings
> can be made at scale through reuse. This goes for code as well :-)

Yes, I'm not fixing a 'global' problem, I'm purposely keeping scope
small for control, understandability, etc. If I got paid a decent amount
of money then it would make sense to go beyond solving the problem I
want to solve.


>> Forgetting about my simple plugin, yes I do agree with the idea of a
>> shared settings store when it comes to things like styles. I guess the
>> next question is, if xfconf is portrayed as an ideal central
>> configuration and changes manager, why do kernel programmers chose to do
>> a similar thing (without change notification mind, theres inotify for
>> that) through RAM-based filesystems (procfs, sysfs etc)?
> 
> Procfs is not that handy. Most files have an awkward syntax that poorly
> interacts
> with C (e.g. environ, you need to parse NUL separated strings and you can't
> figure the size of the entire file because it's a procfs file so you have
> to parse
> blindly until you encounter two NULs in a row; takes a while to figure that
> out).
> No atomic changes, no caching of changes, etc (e.g. GFileMonitor has a
> method it
> uses to cache multiple changes to files in order to reduce the processing
> cost of
> file changes for child applications). THe max size of an environ array is in
> hundreds of megabytes on a modern Linux so you also need a logic to reason
> about
> reading the file in multiple chunks if too big, and a logic to reason about
> whether
> a string you're processing is truncated by your buffer size or not. Not
> funny at
> all to do and I trust few CS students to do this right.
> 
> For me the KISS approach would be to provide proper functions in the system
> call
> interface that have well defined and well scoped semantics, for all commonly
> required operations, rather than let hoards of developers guess how they
> should
> go about parsing complex files that violate some of the expectations of what
> constitutes a file. ;-) Procfs is useful to provide opportunities for
> advanced
> sysadmins / developers who have needs that were not anticipated by the Linux
> developers. I personally would love to have a getenv that takes a damn PID
> as a
> parameter rather than have to write awkward parsers.

Yes thats true - wrapping libraries around this raw data then, like
libgtop for process state, disk usage etc.


>> I'm not sure why you've picked on 'standard place for configuration' a
>> few times, I don't have a problem with using what
>> xfce_panel_plugin_lookup_rc_file provides. I'm not rebelling against
>> desktop organisation.
> 
> Multiple methods of processing config = multiple code bases that need to
> implement
> the same standard. Now given that our upstream GTK+ loves to break their
> own rules
> and existing XDG standards, and that the most popular Xfce distro is based
> on an
> upstream that equally loves to break conventions, we can expect that every
> now and
> then our upstreams will change how their code works, and ours will be
> lagging behind.
> 
> For instance GNOME has changed how they name .desktop files. This has
> forced me
> to rewrite some code (somewhere in GTK+ or Xfce, forgot) that reverse looks
> up
> desktop ids from exec names, which is now much more complex. If a function
> had
> been provided for this by the GLib, I would not have had to triage a bug,
> and then
> patch a piece of software.

> The same goes for our settings backend. The way XfceRc saves changes is not
> compatible with the way GKeyFile works and probably not compatible with
> KDE's
> backend either. So we're producing files that other DEs and apps based on
> other
> toolkits may fail to process properly. By delegating XDG-related operations
> to our
> upstream, we can provide better consistency and reduce our maintenance
> costs.
> 
> Yes, that means delegating control and thus taking risks.

Bad behaviour by upstream 'maintainers' is evidence to drop/fork the
dependencies, not cosy up to them further. If there was a GLib function
etc, presumably they wouldn't maintain it so that it didn't have
breaking changes either?


>> I don't know much about DBus, specifically why its needed compared to
>> more normal alternatives (so now I know it is at least a means for
>> broadcasting configuration changes) - I just see it as extra insecure
>> inefficient complexity. Yes I know that DBus has been attempted to be
>> pushed into the kernel a number of times - I read the reason for pushing
>> it in was to get extra efficiency, but rather it is its
>> design/implementation that is inefficient, so it was rejected.
> 
> DBus is the IPC mechanism used by nearly every Linux applications. In ten
> years
> of CS there are several native IPC mechanisms I've simply never used; this
> is how
> rarely they end up being better than the alternatives. Including DBus thus
> makes
> sense, it serves a purpose.
> 
>> The kernel inclusion is also suspected to be an attempt to engineer
>> insecurity, and possibly further control by RedHat?[0] Can't really
>> comment on that as I don't have any experience here.
> 
> Haha. People come up with such funny ideas :-)

Well, I'm not happy brushing it off like that. IG has earnt his right to
speak to me through his work on the only serious GNU/Linux file manager
I'm aware of, and it does tally up with other complaints I've read
elsewhere. I won't talk about this further since its unlikely to be on
topic enough for this list.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://mail.xfce.org/pipermail/xfce4-dev/attachments/20160516/7e26e93f/attachment.sig>