xfconf VS libxfce4util Resource Config Files for configuration

[OmegaPhil]

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/

-------------- 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/20160510/439ee039/attachment.sig>