Re: [SM-DEVEL] [SM-PLUGINS] [GSoC] Plans for the new configuration and preference system.

[Antoine Delignat-L. <an...@de...>]

Dear Paul,

Thank you for your lengthy comments and all the interesting questions it 
brings up.
> Would it be possible to say SMConfig::Var('var_name') insetad?  I find
> "V" rather cryptic and prefer code that is readable.
>   
The idea was to keep a short way to access a variable, but of course Var 
is not that longer and undoubtedly much clearer. Better change it now 
since there won't be any consequence yet.
>>  The idea behind it is to make the whole system dynamic, which means
>> variables are loaded dynamically without prior information about their
>> nature, so that any plugin can "hook" into the configuration system to
>> register its own configuration variables and user settings.
>>     
>
> As well as override SM config values I hope?  Have you found a worthy
> replacement for the config_override hook in include/init.php, or will
> that hook actually remain untouched?
>
>   
Of course, plugins can add their own variables and change SquirrelMail 
settings too.
I didn't know about this config_override hook, but I reckon it can be 
kept for compatibility with little to no trouble adapting it.

>>  And yet, one of our goal is to replace the current configuration tool (a
>> perl script, config.pl) with a friendlier configuration page. But it is
>>     
>
> This will be really cool to see (and I hope you note the administrator
> plugin has some code that already manages the old SM configuration, so
> you might be able to use some of that code.... also it might be worth
> discussing if the config page you plan should be integrated into or
> replace the current administrator plugin.
>   
I need to investigate more before I comment on this.
> Also, you say "replace the current configuration tool", but what about
> leaving it there for people who don't like the security implications
> of giving the web server write access to the SM configuration
> directory?  Some shared hosting services make changing permissions
> like that a hassle too.  If we basically have two configuration tools
> (but we do now), updating them both is no fun, but I think there might
> be some eyebrows raised when you tell people SM *REQUIRES* write
> permission for the web server on its config directory in order to
> configure it.  Many admins, and especially developers (including
> plugin authors), go tweak the configuration often enough that they
> might feel like they have to leave the write permissions on the config
> directory all the time, which is a nasty security problem we are
> introducing.
>   
Your concerns are justified, but altough there's nothing wrong with the 
current perl script, we'd need to update it to keep it compatible with 
the new format.
>> necessary to have some knowlege about the type of each variable (a boolean,
>> a string, an integer, or even an array or enum) to display the right input
>> mechanism, and maybe a description of the variable, its effects and a
>> category as well.
>>     
>
> Can you elaborate on what a "category" means, at least in actual use?
> Is it only for helping display in the right place in the config tool?
> Does it have any effect in the SM code itself?
>
>   
Categories are indeed used to categorize settings in the config / option 
page and nothing more.
In fact, unless they are needed for that purpose, they won't be parsed 
most of the time (this is true for other "metas"), to save time and memory.

> OK, I see.  Traditionally, SM uses arrays in PHP instead of parsing
> text files.  The advantage of that would be that the information about
> one variable wouldn't be scattered in several places in the same file
> - would be in one place - and that we don't need a parsing engine:
>
> 'imap_auth_mech' => array(
>     'type' => SM_CONF_ENUM,
>     'possible_values' => 'login,plain,cram-md5,digest-md5',
>     'description' => 'Select the authentication mechanism on the IMAP server :',
> ),
>
> This would also be much more similar to the way the SM dynamic options
> page works, which might be useful in some way(s) - you might even be
> able to borrow some code from that system.
>   
Actually, the current preference system uses a serialized text file to 
store options, and I'd like to extend that to script configuration.
Such a text file is quite convenient to parse (and, with an abtract 
parser, you can use other backends like SQL transparently very easily).
It is not necessarily a bad thing to separate metas and actual values, 
mainly because the first is not mutable (you won't change the type or 
the description or a variable) while the last is (that's the point of 
configuration) ; and furthermore, you won't have to parse the metas if 
you don't need them.
Finally, it is easier and less risky to output a simply formated text 
file (e.g org_name = "My $quirrelMail page") than a PHP-formated file 
(<?php $conf = array('org_name' => array('type' => SM_CONF_STRING, 
'description' => "...", "value" => "My \$quirrelMail page")); ?>)
So, I both agree and disagree with you, I'd like to use a format similar 
to the current option system, but not using PHP.

> Oh, and it is more secure than a text file that can be displayed in a
> browser(!!) -- if this just *has* to be a text file, I suggest making
> it a PHP file and wrapping it in a comment block, that is, the first
> line of the file is "<?php /*" and the last line is "*/", without
> quotes of course.  But I'd vote for doing it in PHP in the first
> place.
>   
Actually, I used <?php die(); ?> in my tests but the result is pretty 
much the same.

> Either way, I might suggest that the description is NOT the same as a
> prompt as in your example.  You might want to have both.
>   
Ideally, there should be links to a detailed description of each setting 
in a separate manual or help page. If there is anything planned about 
the help system, I'm very interested to hear it.

> Oh, and what about i18n on the prompts/descriptions?  Is this going to
> be English-only?
>   
Good point. There is no reason not to support i18n, so that english 
won't be required to configure the script (provided that a translation 
exists, of course).
>>  Using the meta-configuration file (or data from whatever backend), the
>>     
>
> "or data from whatever backend" seems like a big point to just gloss
> over.  ;-)  Can you please elaborate?  I'm also curious where/how
> plugins hook in here.
>   
That's nothing to be axcited about, really. The main backend to store 
configuration is a config file, but since user preference will use the 
same system, we should keep support for other backends like SQL or LDAP. 
It's very easy to write a new backend (it works roughly like PHP stream 
wrappers), altough I'm not sure how this could help plugin developers.

>> script can generate a configuration page with suited inputs, categories and
>> descriptions. If a new configuration variable is added into the script in a
>> new release, one line in the meta-configuration file is enough to update the
>> configuration page. Plugins can load their own meta-configuration that gets
>> displayed with other settings (we might define a standard name for plugin
>> meta-configuration files so that they are automatically loaded). And just a
>> few lines are needed to create a template used to generate the whole
>> configuration page.
>>     
>
> Whew, *ONE* page for everything?  That will be a monster page.  The
> current conf.pl tool not only has separate pages for each category,
>   
I didn't mean that all settings are on the same page, we have categories 
to sort all that (they're called groups in the current option system, 
but it's the same thing)
> but it also has subsections on those pages with helpful explanations
> of not only each setting, but of groups of settings on some pages.
> And it does things like hide the SMTP settings when sendmail is being
> used.  How do you plan to replace these things?
>   
I think the most convenient way to bind dependencies (e.g hide sendmail 
path if sendmail is disabled) would be to add a "dependencies" meta, but 
I haven't investigated that matter much yet. I'm not even sure it is 
such a cool idea to hide unrelevant settings, since they don't harm anyone.
>>  Of course, the same applies to user settings. It is quite possible to
>>     
> How will you differentiate between the two?
>   
Using another instance of the config class (e.g $conf = new 
SMConfigFile("config/config_default.php"); $prefs = new 
SMConfigFile($userpath."/prefs.php"); or something similar).
>> generate an option page using variables and descriptors that looks exactly
>> the same as the current static page. But the biggest benefit is probably the
>>     
> The current options pages are not static per se.  There *is* a dynamic
> options system in place and it works nicely methinks.  :-)
>   
You're right of course, now we need to have the same system for script 
configuration.

>> flexibility offered to plugin developers. If someone writes an anti-spam
>> plugin, it would be possible to add a new category in the options page (e.g
>> Spam filter settings) without any patch to the Squirrelmail code.
>>     
> This is currently supported.  Please review that code or take a look
> at any plugin that adds new options blocks or adds options to an
> existing (typically display) options page.  I don't know where you get
> the idea that patching is needed for plugins to add options
> pages/elements.
>   
This is indeed supported for user preferences, but it would be nice to 
support it for script configuration too.

> Are you planning to rip out the current options pages code as well?
>   
Maybe plunder it a little and merge it with script configuration, but 
the general ideas behind (and a lot of code from) the current option 
system will be kept and extended to script configuration.
>>  Since meta-informations are not needed in most cases the script is called,
>> they are not loaded by default to save time and memory. All in all, the
>> execution time to load configuration in most cases (mail reading) will be
>> roughly the same as with the current system.
>>
>>  If anything is unclear of if you have a suggestion or comment, you are
>> welcome to post your ideas or any feedback you might have.
>>     
>
> I'd like to hear more about the design of what happens behind
> SMConfig.
It works like the current option class, with a few more features.
>   The "Configurator" is just a web-based config tool, no
> more? 
I don't know what elese you're expecting, but for now it is.
>  Can you describe what "SMConfigFile, SMConfigSQL ..." is
> (especially the ellipses) and how that differs from "Storage"?
>   
The aim is to provide the various backends for script config and 
(mainly) user preferences, but I admit we are far from decided about how 
we'll implement it.
The current plan is to use SMConfig as a general storage class, that 
needs to be extended by a wrapper class to provide actual I/O functions 
(such as set_value to change the value of a variable), whose behaviour 
depends on the final storage (a SQL backend will send a query, a file 
backend will write in the config file...)
> Thanks!
>
>   Paul
>   
Regards,

Antoine