Configuration API

[Sean Middleditch]

Why don't we come up with a list of use cases and needs for the
configuration API first?  Then come up with an API that meets all those
needs.

Some apps need to store complex data types, for example.  (think
structs, or maybe just associative arrays.)  Do we want lock down and
read-only preferences?  Have to make sure the API can support those;
apps need notification when preferences change between read only and
read write and we probably want API for privileged users/processes to
modify system defaults or lock-down state in a backend-neutral way.

Is this API going to be only actual preferences, or do we also want to
store application state (window position and such) and data (recent
files?) as well?  If yes, the API needs to be able to handle the
oddities of each.  (We don't want a settings-oriented LDAP backend to
store state because that changes very often and LDAP is slow for
writing, for example.)

Do we want/need temporary locks?  For example, if the user is editing
setting /foo/bar in app A, should the API allow it to mark that setting
as "being edited" so that app B won't allow the user to start changing
it there (and causing potential confusing).

The API is a contract with the program which means the backend has to
uphold that contract.  What requirements then do we put on the backend? 
Maybe change notifications are optional.  But do commands that write
multiple values have any kind of guarantee of atomicity?  This could be
fairly important if we go with the above possible need of storing data
or state using this API.  Even preferences may need this as certain
combinations may not make sense or cause problems, so changes that
naturally affect multiple keys must be stored atomically.

Will the API provide built-in rollback features for Undo operations in
apps, or must each and every app reimplement this feature, with many not
even bothering because its too much work?

Are schemas and data sanity/integrity checking mandatory, backend
specific, or something for the app to worry about?

How will the API handle differences between per-user and per-machine
settings, system-wide and session-wide settings, and so on?

Take a look at Havoc's thoughts with GConf here:
http://www.gnome.org/projects/gconf/plans.html

Configuration storage is a very complex problem.  There's a reason
nobody has it anywhere near right yet.  ;-)

On Tue, 2004-04-27 at 10:59, Thomas Leonard wrote:
> For the configuration system, are we agreed that we need a library API?

-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.