Configuration API

[Avi Alkalay]

I agree something must be defined.

Do you guys think it is important for this API to be desktop-apps-only wide,
or also systemwide?
Like, should XFree, Apache configuration be accessible through this API too?

Regards,
Avi


----- Original Message ----- 
From: "Sean Middleditch" <elanthis at awesomeplay.com>
To: <xdg at freedesktop.org>
Sent: Tuesday, April 27, 2004 12:40 PM
Subject: Re: Configuration API


> 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.
>
>
> _______________________________________________
> xdg mailing list
> xdg at freedesktop.org
> http://freedesktop.org/mailman/listinfo/xdg
>