freenode/#clim - IRC Chatlog
Search
7:54:02
scymtym
loke: iiuc, in your requirements document you specify that configuration data should be loadable without the system using it being loaded. you also specify that configuration items have associated types which would presumably be under the control of the system using the options. how does that work?
7:54:03
scymtym
(also, the configuration.options systems meets many of the requirements and could be extended to meet more, but the one related to "bootstrapping" are tough)
8:42:37
loke
scymtym: Things like the editor and the validator would indeed be part of the application that uses the data.
8:43:13
loke
scymtym: This works, because you'd only use those function (like the encoder/decoder/validator) when the system is available.
8:56:57
loke
The storage engine would simply return the lisp structure. The DECODE method would only be called when the application requests the data, at which point all dependencies are obviously available.
8:58:34
scymtym
where the "lisp structure" is created and stored when the configuration file is processed?
9:04:00
loke
scymtym: Well. There is a single function, SET-VALUE that writes a setting to the storage engine. Theis function would pass the argument through the encoder function, which implies that you need to have dependencies available to use it.
9:04:39
loke
However, there is no reason why you couldn't have a funciton that allows you to store a variable directory without the encoder. That would allow the storage of incorrectly formatted data though
9:05:22
loke
One alternative would be to have the validator function act on the backend structure, and let the storage engine store the validator function itself as code
9:24:56
scymtym
loke: there certainly are tradeoffs. what is the downside of processing a separate file, say ~/.config/climrc, lazily. i.e. when the system using the configuration data is loaded or maybe even right before it wants to access the data?
9:26:11
loke
The main purpose of this, hoever, is to be able to ptovide a uniform configuration GUI.
9:26:36
loke
Specifically for CLIM where you'd want to have a single font selector and a single place to configure fonts.
9:29:10
scymtym
a configuration editor would have to use some kind of schema (configuration variable names and types) defined by the clients of the configuration system, right?
9:31:16
scymtym
i'm going to say one final time that the configuration.options system seems like a potential match for the requirements, then shut up about it for good :)
9:41:26
scymtym
loke: more than a few days, i think, but yes, probably. this: https://github.com/scymtym/configuration.options
9:45:28
loke
scymtym: If I want to use a custom backend, can I configure that prior to loading configuration.options?
9:47:24
scymtym
the application has to setup the source(s) (= backend) in any case. so yes, that is possible. there is some builtin support for typical sources such as a cascade of configuration files/directories, environment variables and commandline options