xfconf VS libxfce4util Resource Config Files for configuration

[Steve Dodier-Lazaro]

> 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 :-)

> 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 :-)

> 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.


> 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.

> 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 :-)

On 10 May 2016 at 19:42, OmegaPhil <OmegaPhil at startmail.com> wrote:

> On 02/05/16 19:53, Steve Dodier-Lazaro wrote:
> > 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.
>
>
> Firstly sorry for the significant delay in responding to your mails,
> I've just quoted a bit of the last since theres a lot of content in the
> two in general.
>
> Thanks for your detailed responses, I've had a look around your site etc
> but I can't see a donation email address etc?
>
>
> 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.
>
> Perhaps I don't have the experience - when I see the concept of having
> to depend on a lot of external implementation of these non-core
> functionalities, I just see it as a large amount of external control
> embedded in my code, dragging me along with irrelevant (to the purpose
> of my program) changes (along with large complex alien codebases if I
> need to investigate a problem with them, etc).
>
> 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)?
>
> There you have efficient access to separate blobs of information in a
> defined hierarchy that can be waited on for changes (and there is
> separation of information into multiple files so its not always a case
> of having to parse a large file when something changes etc).
>
> This seems to represent the UNIX/KISS philosophy (interacting with
> plaintext files using standard file tools/functionality).
>
> 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.
>
>
> 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. 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.
>
>
> 0:
>
> https://igurublog.wordpress.com/2015/05/04/kdbus-systemds-kid-cousin-come-to-stay/
>
>
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> https://mail.xfce.org/mailman/listinfo/xfce4-dev
>



-- 
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/20160511/498a9f95/attachment.html>