Requirements and pre-analysis for a cross desktop configuration infrastructure

[Dave Cridland]

On Thu Mar 17 11:03:25 2005, 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? Can we
> keep this platform independent? How will we do this platform-transparant
> on different desktop-systems? Windows, Linux, etc?
> 

The "configuration group" needn't be the same as a permission group. Not even the same kind of group.

But anyway, this is essentially a description of ACAP dataset inheritance. It's relatively easy to handle, especially with the simple notifications that are required. In ACAP, the metadata about inheritance is stored in the data model, incidentally, so, ACLs permitting, a user can actually change this on the fly.

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

Indeed... ACAP has a nice fine-granularity ACL system to go along with the data inheritance.

Be warned that the combination of ACLs and dataset inheritance has caused many people headaches in ACAP. If you're intent on reinventing the wheel yet again, you might want to consider ironing that issue out before starting.

Dave.
--
Currently sharing bookmarks live with a guy in France via ACAP, which is amusing.