Comment 6 for bug 700333

On Thursday 13 January 2011 19:59:20 you wrote:
> Spec looks ok - I guess you wanted it to map nicely to GKeyFile or similar
> "ini" file structure. How about Scheme hooks? s-expr evaluation would be
> difficult here, and config file would accommodate this type of data. Maybe
> a config value with list of extra Scheme files to load - it would have to
> be forbidden/ignored in the "per project" configuration context.

That's correct; my current plan is to use GKeyFile as the storage layer. But
I'd quite like to hide the underlying implementation from the API user, so
that if it comes up towards 1.8.0 and we realise that GKeyFile doesn't cut the
mustard then we only have to change libgeda. ;-)

For per-project Scheme code, my current plan was to allow all config files to
specify plugins to load, but to only allow setting the plugin search path in
user and system config files. I.e. you should have to get the user to install
your nasty Scheme code in an approved plugins directory *and* get them to load
your dodgy gEDA files. Nothing in a config file should *ever* be evaluated.

Once the API spec is done we need to go through *all* the existing "things
people can do in rc files" and work out whether they can be migrated directly,
or whether other changes are needed to facilitate the change (for example,
component libraries, colour maps and print paper sizes all need to have their
underlying mechanisms looked at & possible altered). That'll give us a check
on whether the new config API can actually fulfil all of the roles that it
needs to fill, and, as a side benefit, will provide the information we need to
implement a migration tool to help users upgrade.

It's going to be pretty dull work, unfortunately, but I think it's important
to make sure that if we're going to rip out the existing configuration system
we replace it with something that's going to do the job and do it well!