On 10/30/2015 02:02 PM, Adriano dos Santos Fernandes wrote: > On 30/10/2015 06:59, Alex Peshkoff wrote: >> On 10/29/2015 06:53 PM, Adriano dos Santos Fernandes wrote: >>> On 29/10/2015 13:42, Alex Peshkoff wrote: >>>> On 10/29/2015 06:26 PM, Adriano dos Santos Fernandes wrote: >>>>> Hi! >>>>> >>>>> Initial implementation of external engines didn't needed to edit >>>>> Firebird configuration files. You could just drop files in the plugins >>>>> directory and they worked. >>>>> >>>>> Now that seems broken. File plugins/udr_engine.conf seems to be >>>>> completely unused. >>>>> >>>>> There is a plugins.conf file needing every plugin to be configured there. >>>>> >>>>> That's bad. We know that people (as ourselves as example) will not >>>>> create installer for plugins to edit Firebird config files, leaving >>>>> installation procedures to be done manually by users/admins. >>>> We discussed it a few years ago. You said that time that to provide >>>> installation of plugins you need operator include in .conf files. It >>>> exists for a long time. What else problems? >>>> >>>> >>> I do see this hardcoded: >>> >>> fb_utils::getPrefix(IConfigManager::DIR_CONF, "plugins.conf"), >>> ConfigFile::HAS_SUB_CONF) >>> >>> If one need to include the "include", it's also a file edit that should >>> be avoided. >> Not at all - if we decide to keep .conf files for plugins in >> plugins/conf (or where-ever else) and use wildcard include in plugins.conf: >> >> include $(DIR_PLUGINS)/conf/*.conf >> >> Do you want me to do changes? >> > I think conf file could be directly in $(DIR_PLUGINS), side by side with > the binaries, by convention.
I can agree with it. Just to make it explicit - a method of locating file with _internal_ configuration values by name of plugin with extension changed to .conf must be dropped in that case. Is it OK? ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
