avi at alkalay.net
Tue Apr 27 21:10:11 EEST 2004
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?
----- 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
> 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:
> 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
More information about the xdg