Requirements and pre-analysis for a cross desktop configuration infrastructure

[Joerg Barfurth]

Hi,

Martijn Dekkers wrote:

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

More like a superset of them all. For applications that are only
consumers of configuration data only the client API is interesting. Thus
to ease the transition it should be possible to emulate existing APIs on
top of the new API or protocol.

That does not mean that all features and behaviors of the old systems
must survive. Administration and deployment tools as well as
applications, which heavily depend on very specialized behavior of the
existing applications, will need to be adjusted or rewritten.

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

So you are using source control invocations on each of those desktops to
check out the current configuration files directly into their target
locations? I find that highly unusual. I would think that it should be
sufficient to provide a command for bulk import of files that can be
maintained in source control. Alternatively, with pluggable backends,
you can create a specialized backend that stores the data in a suitable
format directly into a RCS.

> Please make sure that whatever you come up with is:
> 
> * extremely scaleable, 

That surely is desirable. But it is hard to know what that means unless
you are more specific to what kind of scenarios you want this to scale.

> * is easy to manipulate (as in - run *simple* bash scripts against it
> to manipulate values):

What distinguishes simple scripts from others? Do you insist on doing it
all with find/grep/ed? Or would a decent set of CLI tools to query and
set values and to import/export data do - so you can build simple
scripts on top of these tools? I think the latter is a reasonable
requirement, whereas the former isn't.

> * does not need *any* third party crap like GUI's, mono, java, or
> deamons or anything,

Why would "daemons" be considered "third party"? Where is the boundary?
Maybe some people want this to be integrated with their "third party
crap", just as you want this integrated with your RCS. But I agree that
it should not *need* (i.e. require) most of this. Support for pluggable
backends can make this possible. Many people actually like - or even
need - GUIs. But I agree that having a decent CLI is important as well.
And yes, daemons and Java/Mono stuff should not be necessary for basic
things and single machine scenarios. But if they are helpful to scale to
large deployments, then it should possible to use them in such cases.

> * will allow of finely grained version control

I don't think we should build version control into the core system.
Special backends and/or administration tools that interface with the
core system via backend interface or CLI tools should take care of this.

> * can manage multiple environment types, deltas of environments and
> derivative environments. (almost the same thing)

I am not sure I understand your requirement here. Does "the same thing"
refer to RCS support? And what is an "environment type"?

> * any apllication change notification mechanism is out-of-band - i.e.
> not part of the configuration environment - they are architecturally
> seperate functionalities
> 

Why? I don't think that changing raw configuration data, bypassing the
configuration system and its notification mechanisms should be
supported. And of course notifications should be handled by posting
events to an existing signal system (like DBUS). This approach allows
you to ignore notifications at will. Is that "architecturally seperate"
enough?

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

Maybe you should reread this thread, the recent thread about "D-Conf"
and <http://www.freedesktop.org/Standards/config-spec>.

Ciao, Joerg