From: Fredrik J. <sqm...@fi...> - 2006-02-23 09:58:36
|
Hi. I noticed that we have standardised the configuration file names in the SquirrelMail distribution. Now there are only two types: "config_default.php" and "config_sample.php". Are there any special reason for keeping two of them, or should I change all "config_sample.php" to "config_default.php"? If I don't receive any feedback about this, I'll commit a change this weekend. Sincerely, Fredrik. |
From: Thijs K. <ki...@sq...> - 2006-02-23 10:45:14
|
On Thu, 2006-02-23 at 10:58 +0100, Fredrik Jervfors wrote: > Hi. > > I noticed that we have standardised the configuration file names in the > SquirrelMail distribution. Now there are only two types: > "config_default.php" and "config_sample.php". Are there any special reason > for keeping two of them, or should I change all "config_sample.php" to > "config_default.php"? If I don't receive any feedback about this, I'll > commit a change this weekend. I think there's a difference: I'd something called _default to just work when copied to config.php, but _sample would not do that, it could require some tweaking. However, I think we should make plugin installation as easy as possible. So if there's a sensible default configuration that will work in many cases, the _default file should just be called config.php. If such a configuration does not exist (i.e. it really needs some hostname to be set) we should use _sample. Thijs |
From: Fredrik J. <sqm...@fi...> - 2006-02-23 11:07:15
|
>> I noticed that we have standardised the configuration file names in the >> SquirrelMail distribution. Now there are only two types: >> "config_default.php" and "config_sample.php". Are there any special >> reason for keeping two of them, or should I change all >> "config_sample.php" to "config_default.php"? If I don't receive any >> feedback about this, I'll commit a change this weekend. > > I think there's a difference: I'd something called _default to just work > when copied to config.php, but _sample would not do that, it could require > some tweaking. > > However, I think we should make plugin installation as easy as possible. > So if there's a sensible default configuration that will work in many > cases, the _default file should just be called config.php. If such a > configuration does not exist (i.e. it really needs some hostname to be > set) we should use _sample. So "config_default.php" is used when there is no need to configure the plugin unless the administator wants to tweak it. To do so, "config_default.php" is copied to "config.php" and edited. "config_sample.php" is used when the administrator MUST configure the plugin in order to make it work (by copying "config_sample.php" to "config.php" and edit it). On the other hand, SquirrelMail itself provides "config_default.php" and not "config_sample.php" even though it must be configured, so either something is wrong or the theory doesn't hold. It's not acceptable to rename "config_default.php" as "config.php" in the SquirrelMail distribution, because during next upgrade the administrator's configuration will be overwritten. Instead, the default values are included in the plugin itself, but a "config.php" overrides them. Sincerely, Fredrik. |
From: Paul L. <pa...@sq...> - 2006-02-23 11:46:12
|
On 2/23/06, Fredrik Jervfors <sqm...@fi...> wrote: > >> I noticed that we have standardised the configuration file names in th= e > >> SquirrelMail distribution. Now there are only two types: > >> "config_default.php" and "config_sample.php". Are there any special > >> reason for keeping two of them, or should I change all > >> "config_sample.php" to "config_default.php"? If I don't receive any > >> feedback about this, I'll commit a change this weekend. > > > > I think there's a difference: I'd something called _default to just wor= k > > when copied to config.php, but _sample would not do that, it could requ= ire > > some tweaking. > > > > However, I think we should make plugin installation as easy as possible= . > > So if there's a sensible default configuration that will work in many > > cases, the _default file should just be called config.php. If such a > > configuration does not exist (i.e. it really needs some hostname to be > > set) we should use _sample. > > So "config_default.php" is used when there is no need to configure the > plugin unless the administator wants to tweak it. To do so, > "config_default.php" is copied to "config.php" and edited. > "config_sample.php" is used when the administrator MUST configure the > plugin in order to make it work (by copying "config_sample.php" to > "config.php" and edit it). I think you're on the right track. > On the other hand, SquirrelMail itself provides "config_default.php" and > not "config_sample.php" even though it must be configured, so either > something is wrong or the theory doesn't hold. Because I think this has evolved from a time when someone just "did" this, without discussing it like this. I don't personally think it should be called _default, and I don't really think the _local name is indicative of its actual use. I'd rather see these changed. > It's not acceptable to rename "config_default.php" as "config.php" in the > SquirrelMail distribution, because during next upgrade the administrator'= s > configuration will be overwritten. Instead, the default values are > included in the plugin itself, but a "config.php" overrides them. Um, right, if I followed you, I think I agree. This is similar to how some of the more recent plugins from Tomas and myself have been designed: config.php is the "last resort" that overrides all other config files... whereas _default will be the first file that is read by the plugin, however, depending on the plugin, it might need some mandatory configuration by the admin, so it is NOT included in the tarball, and instead a _sample is included in the tarball, which is NEVER read by the plugin. I think I wrote a helper function in the newest compatibility plugin to help automate the inclusion of any number of config files (in the given order) that could be pulled into core if appropriate. - paul |
From: Fredrik J. <sqm...@fi...> - 2006-02-23 16:19:49
|
>>>> I noticed that we have standardised the configuration file names in >>>> the SquirrelMail distribution. Now there are only two types: >>>> "config_default.php" and "config_sample.php". Are there any special >>>> reason for keeping two of them, or should I change all >>>> "config_sample.php" to "config_default.php"? If I don't receive any >>>> feedback about this, I'll commit a change this weekend. >>> >>> I think there's a difference: I'd something called _default to just >>> work when copied to config.php, but _sample would not do that, it >>> could require some tweaking. >>> >>> However, I think we should make plugin installation as easy as >>> possible. So if there's a sensible default configuration that will >>> work in many cases, the _default file should just be called >>> config.php. If such a configuration does not exist (i.e. it really >>> needs some hostname to be set) we should use _sample. >> >> So "config_default.php" is used when there is no need to configure the >> plugin unless the administator wants to tweak it. To do so, >> "config_default.php" is copied to "config.php" and edited. >> "config_sample.php" is used when the administrator MUST configure the >> plugin in order to make it work (by copying "config_sample.php" to >> "config.php" and edit it). > > I think you're on the right track. > >> On the other hand, SquirrelMail itself provides "config_default.php" >> and not "config_sample.php" even though it must be configured, so either >> something is wrong or the theory doesn't hold. > > Because I think this has evolved from a time when someone just "did" > this, without discussing it like this. I don't personally think it should > be called _default, and I don't really think the _local name is indicative > of its actual use. I'd rather see these changed. > >> It's not acceptable to rename "config_default.php" as "config.php" in >> the SquirrelMail distribution, because during next upgrade the >> administrator's configuration will be overwritten. Instead, the default >> values are included in the plugin itself, but a "config.php" overrides >> them. > > Um, right, if I followed you, I think I agree. This is similar to how > some of the more recent plugins from Tomas and myself have been designed: > config.php is the "last resort" that overrides all other config files... > whereas _default will be the first file that is read by the plugin, > however, depending on the plugin, it might need some mandatory > configuration by the admin, so it is NOT included in the tarball, and > instead a _sample is included in the tarball, which is NEVER read by the > plugin. I think I wrote a helper function in the newest compatibility > plugin to help automate the inclusion of any number of config files (in > the given order) that could be pulled into core if appropriate. I was clear as mud, wasn't I? What I meant was that a file called "config.php" should never be part of the ordinary distributions of SquirrelMail or any plugins related to SquirrelMail. (Note that packages for Debian, Fedora e.t.c. may include a "config.php", but this is out of the SquirrelMail Project Team's control.) This helps systems administrators avoid overwriting the "config.php" files and losing all of their setup information when they upgrade SquirrelMail or a plugin. So, if we go with the standard "config_default.php" for plugins that does not need to be configured, and "config_sample.php" for plugins that do need to be configured and for SquirrelMail itself, I'll fix that in SquirrelMail and the documentation and commit it this weekend. (Also see post by Tomas in this thread.) I also think that "config_default.php" shouldn't be read and parsed by any plugin, i.e. that the plugins should nerver rely on a "config_default.php". Instead, the default values should be in the plugin code itself. "config_default.php" is only there to serve as a well commented example to base "config.php" upon when the administrator wants to tweak the plugin. I have no idea why someone would like to (manually or by using "config/conf.pl") configure SquirrelMail by editing "config.php" and then override it with "config_local.php". Why override my own configuration with another configuration of my own? "config_local.php" was introduced "Tue Nov 12 16:13:46 2002 UTC (3 years, 3 months ago) by tassium", but I don't know what problem it was meant to solve. Can anyone enlighten me? Otherwise I vote for removing "config_local.php" and support for it all together. Sincerely, Fredrik. |
From: Paul L. <pa...@sq...> - 2006-02-23 20:08:51
|
On 2/23/06, Fredrik Jervfors <sqm...@fi...> wrote: > >>>> I noticed that we have standardised the configuration file names in > >>>> the SquirrelMail distribution. Now there are only two types: > >>>> "config_default.php" and "config_sample.php". Are there any special > >>>> reason for keeping two of them, or should I change all > >>>> "config_sample.php" to "config_default.php"? If I don't receive any > >>>> feedback about this, I'll commit a change this weekend. > >>> > >>> I think there's a difference: I'd something called _default to just > >>> work when copied to config.php, but _sample would not do that, it > >>> could require some tweaking. > >>> > >>> However, I think we should make plugin installation as easy as > >>> possible. So if there's a sensible default configuration that will > >>> work in many cases, the _default file should just be called > >>> config.php. If such a configuration does not exist (i.e. it really > >>> needs some hostname to be set) we should use _sample. > >> > >> So "config_default.php" is used when there is no need to configure the > >> plugin unless the administator wants to tweak it. To do so, > >> "config_default.php" is copied to "config.php" and edited. > >> "config_sample.php" is used when the administrator MUST configure the > >> plugin in order to make it work (by copying "config_sample.php" to > >> "config.php" and edit it). > > > > I think you're on the right track. > > > >> On the other hand, SquirrelMail itself provides "config_default.php" > >> and not "config_sample.php" even though it must be configured, so eith= er > >> something is wrong or the theory doesn't hold. > > > > Because I think this has evolved from a time when someone just "did" > > this, without discussing it like this. I don't personally think it sho= uld > > be called _default, and I don't really think the _local name is indicat= ive > > of its actual use. I'd rather see these changed. > > > >> It's not acceptable to rename "config_default.php" as "config.php" in > >> the SquirrelMail distribution, because during next upgrade the > >> administrator's configuration will be overwritten. Instead, the defaul= t > >> values are included in the plugin itself, but a "config.php" overrides > >> them. > > > > Um, right, if I followed you, I think I agree. This is similar to how > > some of the more recent plugins from Tomas and myself have been designe= d: > > config.php is the "last resort" that overrides all other config files..= . > > whereas _default will be the first file that is read by the plugin, > > however, depending on the plugin, it might need some mandatory > > configuration by the admin, so it is NOT included in the tarball, and > > instead a _sample is included in the tarball, which is NEVER read by th= e > > plugin. I think I wrote a helper function in the newest compatibility > > plugin to help automate the inclusion of any number of config files (in > > the given order) that could be pulled into core if appropriate. > > I was clear as mud, wasn't I? What I meant was that a file called > "config.php" should never be part of the ordinary distributions of > SquirrelMail or any plugins related to SquirrelMail. (Note that packages > for Debian, Fedora e.t.c. may include a "config.php", but this is out of > the SquirrelMail Project Team's control.) This helps systems > administrators avoid overwriting the "config.php" files and losing all of > their setup information when they upgrade SquirrelMail or a plugin. > > So, if we go with the standard "config_default.php" for plugins that does > not need to be configured, and "config_sample.php" for plugins that do > need to be configured and for SquirrelMail itself, I'll fix that in > SquirrelMail and the documentation and commit it this weekend. (Also see > post by Tomas in this thread.) > > I also think that "config_default.php" shouldn't be read and parsed by an= y > plugin, i.e. that the plugins should nerver rely on a > "config_default.php". Instead, the default values should be in the plugin > code itself. "config_default.php" is only there to serve as a well > commented example to base "config.php" upon when the administrator wants > to tweak the plugin. I disagree. This muddies the value and design of software configuration I think. Having config_default there also allows the config.php for overrides to contain only a subset of all configuration items. > I have no idea why someone would like to (manually or by using > "config/conf.pl") configure SquirrelMail by editing "config.php" and then > override it with "config_local.php". Why override my own configuration > with another configuration of my own? "config_local.php" was introduced > "Tue Nov 12 16:13:46 2002 UTC (3 years, 3 months ago) by tassium", but I > don't know what problem it was meant to solve. Can anyone enlighten me? > Otherwise I vote for removing "config_local.php" and support for it all > together. I don't use it either, and don't really like the way it is named. But I think some people use it to do a quick override of some config item without losing its original setting. I would be OK with removing it. |
From: Daniel W. <d...@ni...> - 2006-02-24 00:25:07
|
[snip] > >>I have no idea why someone would like to (manually or by using >>"config/conf.pl") configure SquirrelMail by editing "config.php" and then >>override it with "config_local.php". Why override my own configuration >>with another configuration of my own? "config_local.php" was introduced >>"Tue Nov 12 16:13:46 2002 UTC (3 years, 3 months ago) by tassium", but I >>don't know what problem it was meant to solve. Can anyone enlighten me? >>Otherwise I vote for removing "config_local.php" and support for it all >>together. > > > I don't use it either, and don't really like the way it is named. But > I think some people use it to do a quick override of some config item > without losing its original setting. I would be OK with removing it. > I'm putting in another vote for keeping it. Some of us have rather more complex config situations. I've had reasonably extensive logic within my config_local.php before that sets certain values depending on certain environment conditions. Admittedly vlogin now solves most of these but it's not inconcievable that there are situations where the config_local.php would be a nice place to put in config logic so that it doesn't break conf.pl. Personally I never use conf.pl (and delete it immediately) because it once overwrote and removed all my non-standard configuration items! [not a bug with conf.pl - just my putting non-standard stuff where it shouldn't be]. My main issue with /config/ is finding out if anything changed. It would be nice to have a config.changelog that shows if any variable has been renamed or added/deleted to the config. currently i have to go through every variable and check its works the same. the config.php has a version number, so why not a changelog? Daniel |
From: Tomas K. <to...@us...> - 2006-02-23 12:11:47
|
> Hi. > > > I noticed that we have standardised the configuration file names in the > SquirrelMail distribution. Now there are only two types: > "config_default.php" and "config_sample.php". Are there any special reason > for keeping two of them, or should I change all "config_sample.php" to > "config_default.php"? If I don't receive any feedback about this, I'll > commit a change this weekend. config_sample.php is included in three plugins. in mail_fetch it can be called config_default.php. File contains default configuration value. in newmail plugin config_sample.php is sample configuration file that includes extra media options. in translate plugin config_sample.php contains code snippets that explain how custom translate backend is configured. It can't be used as default configuration file. -- Tomas |
From: Fredrik J. <sqm...@fi...> - 2006-02-26 11:07:28
|
>> Hi. >> >> I noticed that we have standardised the configuration file names in the >> SquirrelMail distribution. Now there are only two types: >> "config_default.php" and "config_sample.php". Are there any special >> reason for keeping two of them, or should I change all >> "config_sample.php" to "config_default.php"? If I don't receive any >> feedback about this, I'll commit a change this weekend. > > config_sample.php is included in three plugins. > > in mail_fetch it can be called config_default.php. File contains default > configuration value. > > in newmail plugin config_sample.php is sample configuration file that > includes extra media options. > > in translate plugin config_sample.php contains code snippets that explain > how custom translate backend is configured. It can't be used as default > configuration file. I've committed the change for "mail_fetch". Since "newmail" and "translate" provides both a "config_default.php" and a "config_sample.php", there is no need for changing anything regarding those plugins (at least not now). Sincerely, Fredrik. |
From: Tomas K. <to...@us...> - 2006-02-23 16:54:02
|
>>>>> I noticed that we have standardised the configuration file names >>>>> in the SquirrelMail distribution. Now there are only two types: >>>>> "config_default.php" and "config_sample.php". Are there any >>>>> special reason for keeping two of them, or should I change all >>>>> "config_sample.php" to "config_default.php"? If I don't receive >>>>> any feedback about this, I'll commit a change this weekend. >>>> >>>> I think there's a difference: I'd something called _default to just >>>> work when copied to config.php, but _sample would not do that, it >>>> could require some tweaking. >>>> >>>> However, I think we should make plugin installation as easy as >>>> possible. So if there's a sensible default configuration that will >>>> work in many cases, the _default file should just be called >>>> config.php. If such a configuration does not exist (i.e. it really >>>> needs some hostname to be set) we should use _sample. >>> >>> So "config_default.php" is used when there is no need to configure >>> the plugin unless the administator wants to tweak it. To do so, >>> "config_default.php" is copied to "config.php" and edited. >>> "config_sample.php" is used when the administrator MUST configure the >>> plugin in order to make it work (by copying "config_sample.php" to >>> "config.php" and edit it). >>> >> >> I think you're on the right track. >> >> >>> On the other hand, SquirrelMail itself provides "config_default.php" >>> and not "config_sample.php" even though it must be configured, so >>> either something is wrong or the theory doesn't hold. >> >> Because I think this has evolved from a time when someone just "did" >> this, without discussing it like this. I don't personally think it >> should be called _default, and I don't really think the _local name is >> indicative of its actual use. I'd rather see these changed. >> >>> It's not acceptable to rename "config_default.php" as "config.php" in >>> the SquirrelMail distribution, because during next upgrade the >>> administrator's configuration will be overwritten. Instead, the >>> default values are included in the plugin itself, but a "config.php" >>> overrides them. >> >> Um, right, if I followed you, I think I agree. This is similar to how >> some of the more recent plugins from Tomas and myself have been >> designed: >> config.php is the "last resort" that overrides all other config files... >> whereas _default will be the first file that is read by the plugin, >> however, depending on the plugin, it might need some mandatory >> configuration by the admin, so it is NOT included in the tarball, and >> instead a _sample is included in the tarball, which is NEVER read by >> the plugin. I think I wrote a helper function in the newest >> compatibility plugin to help automate the inclusion of any number of >> config files (in the given order) that could be pulled into core if >> appropriate. > > I was clear as mud, wasn't I? What I meant was that a file called > "config.php" should never be part of the ordinary distributions of > SquirrelMail or any plugins related to SquirrelMail. (Note that packages > for Debian, Fedora e.t.c. may include a "config.php", but this is out of > the SquirrelMail Project Team's control.) This helps systems > administrators avoid overwriting the "config.php" files and losing all of > their setup information when they upgrade SquirrelMail or a plugin. > > So, if we go with the standard "config_default.php" for plugins that does > not need to be configured, and "config_sample.php" for plugins that do > need to be configured and for SquirrelMail itself, I'll fix that in > SquirrelMail and the documentation and commit it this weekend. (Also see > post by Tomas in this thread.) > > I also think that "config_default.php" shouldn't be read and parsed by > any plugin, i.e. that the plugins should nerver rely on a > "config_default.php". Instead, the default values should be in the plugin > code itself. "config_default.php" is only there to serve as a well > commented example to base "config.php" upon when the administrator wants > to tweak the plugin. It is easier to locate configuration options, when they are in one file and that file contains only configuration options. My plugins don't depend on config_default.php. If somebody removes config_default.php, default options are loaded in functions.php. SquirrrelMail should also load default configuration values in order to fix issues with outdated config.php files. > I have no idea why someone would like to (manually or by using > "config/conf.pl") configure SquirrelMail by editing "config.php" and then > override it with "config_local.php". Why override my own configuration > with another configuration of my own? >"config_local.php" was introduced "Tue > Nov 12 16:13:46 2002 UTC (3 years, 3 months ago) by tassium", but I > don't know what problem it was meant to solve. Can anyone enlighten me? > Otherwise I vote for removing "config_local.php" and support for it all > together. It allows to use custom configuration options without modifying configuration script. Some options are not supported by conf.pl I vote for keeping it. -- Tomas |
From: Fredrik J. <sqm...@fi...> - 2006-02-26 12:41:59
|
>> I also think that "config_default.php" shouldn't be read and parsed by >> any plugin, i.e. that the plugins should nerver rely on a >> "config_default.php". Instead, the default values should be in the >> plugin code itself. "config_default.php" is only there to serve as a >> well commented example to base "config.php" upon when the administrator >> wants to tweak the plugin. > > It is easier to locate configuration options, when they are in one file > and that file contains only configuration options. > > My plugins don't depend on config_default.php. If somebody removes > config_default.php, default options are loaded in functions.php. > > SquirrrelMail should also load default configuration values in order to > fix issues with outdated config.php files. > >> I have no idea why someone would like to (manually or by using >> "config/conf.pl") configure SquirrelMail by editing "config.php" and >> then override it with "config_local.php". Why override my own >> configuration with another configuration of my own? "config_local.php" >> was introduced "Tue Nov 12 16:13:46 2002 UTC (3 years, 3 months ago) by >> tassium", but I don't know what problem it was meant to solve. Can >> anyone enlighten me? Otherwise I vote for removing "config_local.php" >> and support for it all together. > > It allows to use custom configuration options without modifying > configuration script. Some options are not supported by conf.pl > > I vote for keeping it. As I see it, there are four ways to provide default configuration, and currently we use all of them but the fourth one. Wouldn't it be nicer to use just one of them, and also add that as the preferred solution in the documentation? The four ways are: 1. Code the default configuration within the plugin (typically "functions.php"), meaning that the plugin won't depend on "config_default.php". Instead, "config_default.php" is only there to serve as a well commented example to base "config.php" upon when the administrator wants to tweak the plugin. If the administrator loses, truncates, or changes "config_default.php", nothing really happens. On the other hand, there will be two places to maintain defaults at. 2. Code the default configuration in "config_default.php" and make the plugin depend on it. The advantage is that the defaults are only coded once, making the code easy to maintain, but if the administrator loses, truncates, or changes "config_default.php", the plugin might break. 3. If there's a "config_default.php" we use it, but if not the default configuration is within the plugin (typically "functions.php"). This is also two defaults to maintain in parallel, but if "config_default.php" is lost, nothing happens since the hard coded defaults will kick in. However, if "config_default.php" is truncated or changed, the plugin might break. 4. First use the hard coded defaults, then override them using "config_default.php", and then override them with "config.php". Still; two defaults to maintain, but if "config_default.php" is lost, truncated, or changed, the plugin is still likely to work. Regarding "config_local.php" for SquirrelMail itself, there appear to be a point of having a configuration file that's not affected by "config/conf.pl", so I guess we should keep it. If there are suggestions for a better name for it, let's discuss them. If there are no objections, I will change "config_default.php" to "config_sample.php" for SquirrelMail itself next weekend, and at the same time commit the changed name for "config_local.php", if we agree on a better one. Sincerely, Fredrik. |