dotgnu-general
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [DotGNU]SEE configuration poll


From: Rhys Weatherley
Subject: Re: [DotGNU]SEE configuration poll
Date: Fri, 23 Aug 2002 07:17:36 +1000

S11001001 wrote:
> 
> The SEE is started at boot, and also by each user.
> 
> Each user can provide webservices by registering them in his/her own
> config file.
> 
> Each user (and the system) can specify different plugins available using
> the same config file.
> 
> The way I see it, there are two KISS options for this system:

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 guile/M4 and XML were the only choices, I'd go with XML.

Personally, I loathe configuration files.  My philosophy has
always been that a program's default mode out of the box, with
no a priori configuration, must be what the majority of users
expected in the first place.  In the case of SEE, it would be
"useful plugins enabled, dangerous plugins disabled, with all
security options set at maximum".

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?

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.

Cheers,

Rhys.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]