Requirements and pre-analysis for a cross desktop configuration infrastructure

[cobaco (aka Bart Cornelis)]

On Thursday 17 March 2005 12:03, Philip Van Hoof wrote:
> On Thu, 2005-03-17 at 11:37 +0100, cobaco (aka Bart Cornelis) wrote:
> > On Thursday 10 March 2005 21:15, Philip Van Hoof wrote:
> > > The backend  needs to support default settings which are stored on a
> > > for the users  read-only  location. For  example: the  user  settings
> > > go  in $HOME/.dconf/ and the defaults go in /etc/dconf/default/.
> >
> > it needs more then that:
> > - it needs what kde calls 'cascading configuration', i.e. multiple
> > configuration sets that can be stacked, and activated conditionally
> > (say one set of configuration for admins, one for management, and one
> > for ordinary office workers, stacked on top of common base-settings)
>
> That means that you need to add some sort of meta-information to the
> user-accounts of the system that tells what type of user it is? 
well, yes and no, with everything but gnome (AFAIK) it's just a matter of 
setting an environment variable to the right list of basedirs on x-startup

I do this as follows on Debian:
- I have a set of metadatafiles for each profile, these basically contain 
 - profile name
 - profile type (KDE, GCONF, XDG_DATA, XDG_CONFIG, ROX, UDE, GNUSTEP)
 - profile location
 - profile precedence (used to order the sets in case several are active)
 - profile requirement -> decided by group membership or 
       succesfull completion of an arbitrary shell command
 - profile description
- on X-startup an Xsession script is run that looks at the metadatafiles and 
based on the requierements they state sets up the correct environment 
variables (or generates path files in case of GCONF) so the profiles get 
activated.

> Can we keep this platform independent? How will we do this 
platform-transparant on different desktop-systems? Windows, Linux, etc?

different desktop-systems yes (my scripts do that already), 

anything Unix with X11 should be possible (xsession scripts are possible 
pretty much anywhere that runs X11, right?)

The actual requirements will differ (but those are up to the admin of the 
box to decide anyway), but the mechanism can be pretty much universal I 
think. The only Debian-specific bits in my scripts are: 
- use of the errormsg function defined by Debian's Xsession script for error 
reporting
- use of tempfile function from debian-utils (gets good tempfile 
location/name)

If you want to take a look at my scripts a tarball (and deb package) can be 
found at http://developer.skolelinux.no/~cobaco/desktop-profiles (also 
includes a kmdr-gui script for administering the metadata files)

> > -> the basedir spec provides for the stacking
> >
> > merging of the different configuration sets should with be done with a
> > granularity of individual settings (not config files). And ideally
> > there should be a mechanism to mark settings as can't be changed by
> > user (similar to kde kiosk system)
>
> Okay. I can see a use for that. So far I haven't seen applications that
> heavily depend on read-only -ness of configuration keys. But I can
> imagine that some distributors like to create such configuration-keys as
> read-only and not-by-the-user -over writable. Of for, indeed, kiosks.

It's not the applications that depend on it, it's an admin thing -> you want 
to be able to enforce the corporation wide standards (e.g. make sure people 
can't accidentally change the mail server settings of the corporate 
account, making them call the helpdesk with a my mail doesn't work anymore)
-- 
cobaco (aka Bart Cornelis):
    Coördinator Belgisch Skolelinux team
    Coördinator Nederlandse Skolelinux vertaling
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050317/122e2753/attachment.pgp