Re: [DotGNU]SEE configuration poll

[Barry Fitzgerald]

Rhys Weatherley wrote:
> 
> It may be best to first list precisely what would go into
> a SEE configuration file.
> 
> The guile/M4 system is essentially a programming language
> in its own right.  Ordinary users are unlikely to have the
> skills necessary to update it.
> 
> Rasterman recently pointed out that Enlightment's choice of
> such a rich theme format was a mistake.  It was so complicated
> that very few people were able to build themes.
> 

If Rasterman lists it as a problem with enlightenment, I say we listen.  

(in the background, I'm having bad memories of trying to configure
sendmail for the first time. :) )...




> A big problem with configuration files is that migration
> between versions is very hard.  How do you update everyone's
> configuration file when a new plugin comes standard with
> a new version of SEE?
> 

My take on this is to deprecate fields slowly and to have the
installation script migrate out your settings to the new config.  This
can be accomplished (I'll use XML as an example, but really this could
be accomplished by loading any config file) by doing the following:

1) Load the DOM into memory from the config file(s) using any old
formats.
2) Dump the DOM representation into a new XML file (after saving the
original, of course).
3) Reload the config file(s) to be sure that they parse and match the
original DOM.  If they don't, then report the errors to the user and
replace the new XML files that failed with the original ones.

That's the best procedure that I can think of to solve the situation.



> There are other ways to register plugins.  For example, if
> a suitably named executable/library is in the right directory,
> it is a plugin.  The pnet compiler uses this: it searches
> "$prefix/lib/cscc/plugins" for language plugins.  Adding a
> new plugin is as simple as dropping a file or a symlink in
> that directory.  No other user action is necessary.
> 
> In this scenario, very little user configuration is needed.
> A simple flag "plugin_X_enabled=yes" may be sufficient.
> If the plugin needs parameters, then "plugin_X_params=???".
> Even XML would be overkill for something like this.
> 


I think that this is a good way to do it (create a plugins directory). 
I, personally, see the best way of doing this as to create a plugins
directory and then populate it with XML files referring to the plugin. 
This way, plugins can be saved elsewhere on the drive and, if
accessible, can be loaded by the user using the SEE.  It also creates a
possible opening for creating a jailed environment.  I really do see
these XML files, personally, as being policy settings for the various
plugins and potentially for applications.  These "policy files" could,
potentially, get rather large.

        -Barry