Requirements and pre-analysis for a cross desktop configuration infrastructure

[Martijn Dekkers]

Hi,

Thanks for an informative post.

> A configuration management  and  storage  system   that  can be used  on
> multiple platforms (for  example Linux,  *BSD,  Windows,  Mac,  etc). It
> needs  to  be  very  easily  to  integrate  existing  applications  and
> technologies with  it. Making this difficult will hinder the acceptation
> by developers of existing applications.

Hmm, like, a lowest common denominator between all platforms?
 
> In a future somewhere on the island Utopia  could  such  a  notification
> system notify  panel  applets  and  other  applications about the screen
> resolution  being  changed,  or  monitors  being  added to the dual-head
> configuration. But perhaps are such events better handled by X11 signals
> and atoms. I'm not sure a configuration system should be responsible for
> notifying  applications  about  this  type of events. Whether it should,
> needs investigation and lots of talking with the people involved.

If you have X deal with this, won't windows and Mac be left out from
your list above? Maybe I just don't understand.
 
> Some "geeks" use a source control system for managing changes  in  their
> home directory. I don't see this  as a  required  something  to support.
> Perhaps the  ability  to  freeze  writing  to the backend so that backup
> applications  can  instruct the configuration daemon not to write for a
> certain amount of time or until the unfreeze command is given.

This "geek" uses a source control system to store text-based
configuration files that control a large array of applications and
services to manage well in excess of 46000 (not a typo) linux desktops
(KDE, if you ask), and a bit over 2700 servers for several different
customers. If you think of breaking text based config files and
replacing it with something horrid and that does not at the very least
have change control, I will have to hunt you down and destroy your
keyboard.

Please make sure that whatever you come up with is:

* extremely scaleable, 
* is easy to manipulate (as in - run *simple* bash scripts against it
to manipulate values):
* does not need *any* third party crap like GUI's, mono, java, or
deamons or anything,
* will allow of finely grained version control
* can manage multiple environment types, deltas of environments and
derivative environments. (almost the same thing)
* any apllication change notification mechanism is out-of-band - i.e.
not part of the configuration environment - they are architecturally
seperate functionalities

If I'll think about it hard I can probably come up with more.

What I personally fail to see is what problem you are fixing.

Thanks

 -- Martijn