basedir-spec: machine specific config files

[Niels Ole Salscheider]

Hello,

> Do you have a provision for handling hundreds of clients with the same
> hardware? At the moment, for e.g. ~/.config/monitors.xml, the data is
> keyed on monitor type (name, product ID, etc.), so it's possible to
> configure your preferred resolution for e.g. all Dell 2407WFPs at once.
> (Granted, in implementation this doesn't work amazingly and I've seen
> people end up with monitors.xml files specifying 800x600 on all monitors
> unconditionally, but that's an implementation bug, not a design flaw.)

In theory, this should be a solution. But if we leave it to the application 
developer to come up with a solution to handle different hardware everyone will 
implement it in another way creating quite a mess. And I bet there will be 
some that do not care at all.

> In your proposal, there isn't actually a good way to make changes that
> appear on the same hardware. We run 400+ networked machines with more or
> less identical hardware (on purpose) with shared home directories. As
> rooms get reconfigured, spaces change, etc., we might add or remove
> machines at any time. The best solution I can see in your proposal is to
> have a script to create 400+ symlinks hard-coding each machine hash.
> Meanwhile, the current setup already works fine, so this wouldn't make
> things any better in networked homedirs as we implement them.

That is indeed a problem. We could fall back to a default config directory if 
there is no available with the unique hardware id. This would work for 
companies, universities, ... like today but would not solve the problem when 
you have several hundred machines with hardware configuration 1 and another 
thousand with completely different configuration 2. I have no idea how to solve 
this at the moment, though.

> Do you have a specific use case in mind? For devices with radically
> different form factors, does it actually make sense to use the same home
> directory (are you currently doing this)?

My use case is two somewhat different desktop computers which share /home and a 
notebook, on which I rsync /home each time I leave / come back. All these 
computers run the same software, but some settings have to be different.
Since KDE plasma active is supposed to run on tablets and similar touch-
enabled devices, I think there might be even more problems if someone tries to 
share /home with it in the future.

> And even if so, wouldn't it make sense for some of those devices to just
> change $XDG_CONFIG_DIR to, say, ~/.config.tablet?

I would not mind a solution similar to that for my use case. That is, I would 
change $XDG_MACHINE_DIR to some non-defalut location on login, but I'd like to 
keep the hardware independent config in sync.

> (By the way, were you to implement this, please see if using
> /var/lib/dbus/machine-id instead of your own machine hash function will 
> meet your needs.)

Maybe, a unique machine id is not a good idea after all. What about reading a 
"hardware platform id" from some global configuration file that would be 
identical on identical hardware (e. g. in a company)?

> 2) higher level: based on branches in a version control system, I can have
> different stuff $XDG_CONFIG_HOME the additional benefit heres is that you can
> merge from one branch to another, also with a VCS you can have a good "mix
> and match" between branches with things like git submodules and
> svn:externals, while maintaining full diff-ablities and not having stuff
> that are not needed checked out in your home directory.  With a system like
> you describe I can't see a workflow that allows those 3 at the same time.

You are right, that will not work. But is it really necessary to "not having 
stuff that are not needed checked out in your home directory"? I do not see how 
this will be a real problem if you are using e. g. three different hardware 
platforms that do not share machine-specific config?
I am not sure there are many who want to use a vcs for config file management, 
but these who want could still use a vcs in the default config directory.

I am not saying my proposal is the way to go, it is just an idea I came up 
with to solve my use case. I am happy if there are better proposals how to 
solve it.

Kind regards,

Ole
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20110922/b9358daf/attachment.pgp>