Re: [Firebird-devel] Cannot easily install plugins

2015-11-05 Thread Alex Peshkoff
On 11/04/2015 01:07 PM, Adriano dos Santos Fernandes wrote:
> On 31/10/2015 11:41, Alex Peshkoff wrote:
>> On 10/30/2015 08:53 PM, Adriano dos Santos Fernandes wrote:
>>> On 30/10/2015 11:57, Alex Peshkoff wrote:
 On 10/30/2015 04:00 PM, Adriano dos Santos Fernandes wrote:
> On 30/10/2015 10:57, Adriano dos Santos Fernandes wrote:
>> On 30/10/2015 10:53, Dimitry Sibiryakov wrote:
>>> 30.10.2015 13:35, Adriano dos Santos Fernandes wrote:
 I said that external plugins are not loaded without editing Firebird
 supplied configuration files.
>>>   Avalerion's CDC plugin is loaded perfectly well without editing 
>>> plugins.conf.
>>>
>> What's the [Firebird] type of this plugin?
>>
> And, does it uses a .conf file through the API plugin?
>
> Of course, this is what I want, in addition to an easy-install approach,
> use the plugin's config within the Firebird plugin API.
>
 Plugins can be loaded without changes in plugins.conf (the only one
 plugin which needs it is UDR, the reason is plugin name does not match
 executable module name). I suppose that after renaming libudr_engine.so
 to libUDR.so parameter
Module = $(root)/plugins/udr_engine
 will not be needed.

>>> Well, but UDR is an "external language", it's not (necessarily) a plugin.
>>>
>>> A plugin may have many languages and other things.
>>>
>>> When you get the language name (from metadata) and try a file (plugin)
>>> name, something is wrong.
>> A file and plugin names are not same things in general case. First of
>> all it's necessary to mention that "plugin name" is not absolutely
>> correct term - there are 3 different plugin names.
>>
>> First (and most permanent) is "Registered name" (or factory name) - a
>> name which plugin reports to plugin manager when registers in the system.
>> iPlugin->registerPluginFactory(IPluginManager::TYPE_AUTH_SERVER,
>> RemotePassword::plugName, );
>> (in this case it is RemotePassword::plugName)
>> Registered name is given by a plugin author and can not be changed later.
>> Next is "Plugin module name". In simple case it matches registered name,
>> but certainly in single module one can have more than single plugin's
>> factory.
>> Third is "Configured plugin name" - it's a name which is provided for
>> plugin in plugins.conf and under which it's known to plugin manager.
>> In simple case all 3 names match, therefore avoiding need in
>> configuration in plugins.conf.
>>
>> Returning to UDR - as far as I understand when you say that a plugin may
>> have many languages you mean that in single plugin module may be placed
>> more than 1 plugin's factory for different languages, and name of each
>> factory will match that language name from metadata. In such case plugin
>> does need to be configured in plugins.conf and we return to the problem
>> we have started with - how to install plugin without editing
>> plguins.conf. Am I right?
>>
> Looks like plugins are loaded on-demand,

Yes.

> and the problems come from that.

Not only, though in a particular case with UDR it probably can help.

But imagine a more generic case - company X has 2 plugin modules 
containing each some plugins without source code but with same 
registration names. That plugins should be loaded in parallel. Renaming 
a file with plugin module is trivial, but how to reference that plugins 
later? Module.RegistratioName? And how to provide configuration for 
them? Or another case - same plugin should be used in different 
databases with different configuration. Only flexible configuration file 
can help.

> IMO all plugins should be loaded.

Specially on client - engine12 :) Yes I understand that computers have 
today a lot of RAM but may be some better use of it can be found than 
loading unused code. I.e. I agree with Vlad here - bad idea.

> They can then load their components on-demand if appropriate.
>

A way to move some complexity from single place (plugin manager) to all 
plugins.
I prefer to load some configuration file than to suggest people to make 
plugins more and more complex.


The only problem I see now is install. But it can be solved in simpler 
way. We can add per-plugin configuration files of 2 kinds - instructions 
for plugin manager how to load and configure particular plugin and 
configuration of plugin itself. I've initially suggested to place them 
in different dirs, but certainly that's not the only one solution. We 
may place all configuration to plugins, but have different extensions 
for plugin manager configuration and plugin configuration. For example 
in plugins will be present for udr: libudr_engine.so, udr.pman - plugin 
manager configuration:

Plugin = UDR
{
 Module = udr_engine
}

and UDR.conf:

path = $(root)/plugins/udr

In plugins.conf will be present single line:

include (DIR_PLUGINS)/*.pman

That's an approach, used in a lot of *nix daemons (line xinetd), and it 
showed itself to be fine.



Re: [Firebird-devel] Cannot easily install plugins

2015-11-04 Thread Adriano dos Santos Fernandes
On 31/10/2015 11:41, Alex Peshkoff wrote:
> On 10/30/2015 08:53 PM, Adriano dos Santos Fernandes wrote:
>> On 30/10/2015 11:57, Alex Peshkoff wrote:
>>> On 10/30/2015 04:00 PM, Adriano dos Santos Fernandes wrote:
 On 30/10/2015 10:57, Adriano dos Santos Fernandes wrote:
> On 30/10/2015 10:53, Dimitry Sibiryakov wrote:
>> 30.10.2015 13:35, Adriano dos Santos Fernandes wrote:
>>> I said that external plugins are not loaded without editing Firebird
>>> supplied configuration files.
>>  Avalerion's CDC plugin is loaded perfectly well without editing 
>> plugins.conf.
>>
> What's the [Firebird] type of this plugin?
>
 And, does it uses a .conf file through the API plugin?

 Of course, this is what I want, in addition to an easy-install approach,
 use the plugin's config within the Firebird plugin API.

>>> Plugins can be loaded without changes in plugins.conf (the only one
>>> plugin which needs it is UDR, the reason is plugin name does not match
>>> executable module name). I suppose that after renaming libudr_engine.so
>>> to libUDR.so parameter
>>>   Module = $(root)/plugins/udr_engine
>>> will not be needed.
>>>
>> Well, but UDR is an "external language", it's not (necessarily) a plugin.
>>
>> A plugin may have many languages and other things.
>>
>> When you get the language name (from metadata) and try a file (plugin)
>> name, something is wrong.
> A file and plugin names are not same things in general case. First of 
> all it's necessary to mention that "plugin name" is not absolutely 
> correct term - there are 3 different plugin names.
>
> First (and most permanent) is "Registered name" (or factory name) - a 
> name which plugin reports to plugin manager when registers in the system.
> iPlugin->registerPluginFactory(IPluginManager::TYPE_AUTH_SERVER, 
> RemotePassword::plugName, );
> (in this case it is RemotePassword::plugName)
> Registered name is given by a plugin author and can not be changed later.
> Next is "Plugin module name". In simple case it matches registered name, 
> but certainly in single module one can have more than single plugin's 
> factory.
> Third is "Configured plugin name" - it's a name which is provided for 
> plugin in plugins.conf and under which it's known to plugin manager.
> In simple case all 3 names match, therefore avoiding need in 
> configuration in plugins.conf.
>
> Returning to UDR - as far as I understand when you say that a plugin may 
> have many languages you mean that in single plugin module may be placed 
> more than 1 plugin's factory for different languages, and name of each 
> factory will match that language name from metadata. In such case plugin 
> does need to be configured in plugins.conf and we return to the problem 
> we have started with - how to install plugin without editing 
> plguins.conf. Am I right?
>
Looks like plugins are loaded on-demand, and the problems come from that.

IMO all plugins should be loaded. They can then load their components
on-demand if appropriate.


Adriano


--
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Cannot easily install plugins

2015-11-04 Thread Vlad Khorsun
04.11.2015 12:07, Adriano dos Santos Fernandes wrote:

> Looks like plugins are loaded on-demand, and the problems come from that.
>
> IMO all plugins should be loaded.

   I'm against such nonsense, sorry. Or i not understand you (it happens)

Regards,
Vlad


--
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Cannot easily install plugins

2015-10-31 Thread Alex Peshkoff
On 10/30/2015 08:53 PM, Adriano dos Santos Fernandes wrote:
> On 30/10/2015 11:57, Alex Peshkoff wrote:
>> On 10/30/2015 04:00 PM, Adriano dos Santos Fernandes wrote:
>>> On 30/10/2015 10:57, Adriano dos Santos Fernandes wrote:
 On 30/10/2015 10:53, Dimitry Sibiryakov wrote:
> 30.10.2015 13:35, Adriano dos Santos Fernandes wrote:
>> I said that external plugins are not loaded without editing Firebird
>> supplied configuration files.
>  Avalerion's CDC plugin is loaded perfectly well without editing 
> plugins.conf.
>
 What's the [Firebird] type of this plugin?

>>> And, does it uses a .conf file through the API plugin?
>>>
>>> Of course, this is what I want, in addition to an easy-install approach,
>>> use the plugin's config within the Firebird plugin API.
>>>
>> Plugins can be loaded without changes in plugins.conf (the only one
>> plugin which needs it is UDR, the reason is plugin name does not match
>> executable module name). I suppose that after renaming libudr_engine.so
>> to libUDR.so parameter
>>   Module = $(root)/plugins/udr_engine
>> will not be needed.
>>
> Well, but UDR is an "external language", it's not (necessarily) a plugin.
>
> A plugin may have many languages and other things.
>
> When you get the language name (from metadata) and try a file (plugin)
> name, something is wrong.

A file and plugin names are not same things in general case. First of 
all it's necessary to mention that "plugin name" is not absolutely 
correct term - there are 3 different plugin names.

First (and most permanent) is "Registered name" (or factory name) - a 
name which plugin reports to plugin manager when registers in the system.
iPlugin->registerPluginFactory(IPluginManager::TYPE_AUTH_SERVER, 
RemotePassword::plugName, );
(in this case it is RemotePassword::plugName)
Registered name is given by a plugin author and can not be changed later.
Next is "Plugin module name". In simple case it matches registered name, 
but certainly in single module one can have more than single plugin's 
factory.
Third is "Configured plugin name" - it's a name which is provided for 
plugin in plugins.conf and under which it's known to plugin manager.
In simple case all 3 names match, therefore avoiding need in 
configuration in plugins.conf.

Returning to UDR - as far as I understand when you say that a plugin may 
have many languages you mean that in single plugin module may be placed 
more than 1 plugin's factory for different languages, and name of each 
factory will match that language name from metadata. In such case plugin 
does need to be configured in plugins.conf and we return to the problem 
we have started with - how to install plugin without editing 
plguins.conf. Am I right?



--
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Cannot easily install plugins

2015-10-30 Thread Dimitry Sibiryakov
30.10.2015 12:24, Alex Peshkoff wrote:
> You did not pay attention to
>> >There are 2 types of plugin configuration
> As a minimum them must be separated one from another

   Frankly, I see no point in "two types of plugin configuration".

-- 
   WBR, SD.

--
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Cannot easily install plugins

2015-10-30 Thread Dimitry Sibiryakov
30.10.2015 12:28, Alex Peshkoff wrote:
> 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?

   To make explicit:

a) Every plugin has PluginName, ModuleName, ConfigFileName
b) By default (without any additional editing of plugins.conf)
   ModuleName = plugins/$(PluginName).dll
   ConfigFileName = $(basename ModuleName).conf
c) File, determined by ConfigFileName is a plain set of pairs "Option=Value".

   Agree?

-- 
   WBR, SD.

--
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Cannot easily install plugins

2015-10-30 Thread Alex Peshkoff
On 10/30/2015 12:46 PM, Dimitry Sibiryakov wrote:
> 30.10.2015 9:59, Alex Peshkoff wrote:
>> 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?
> Before doing that consider the case when two different plugins have 
> setting with the
> same name but different meaning.
> It would be too cruel to make every plugin-related config file to use 
> full syntax
> instead of simple "setting=value".
>

There are 2 types of plugin configuration - instructions for plugin 
manager (read from plugins.conf) and internal plugin configuration 
values. Placed into plugins.conf info is enclosed for each plugin into 
{} braces:
Plugin=SomePlug
{
 Name1=Value
 Name2=OtherValue
...
}

When writing include file one anyway must have Plugin-Name and {} pair 
in it, i.e. here we have no problems with mixed names. What about 
internal configuration values - certainly your scenario is possible, how 
we try to resolve conflicts in described in doc/README.plugins.html


--
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Cannot easily install plugins

2015-10-30 Thread Dimitry Sibiryakov
30.10.2015 13:25, Alex Peshkoff wrote:
> But Adriano is talking about a place for information that currently must
> go into plugins.conf and we try to find a solution that does not require
> editing plugins.conf when such info must be set on plugin install.

   AFAIU, Adriano said that config from default ConfigFileName is not read now 
and his 
plugin cannot get it.

-- 
   WBR, SD.

--
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Cannot easily install plugins

2015-10-30 Thread Adriano dos Santos Fernandes
On 30/10/2015 10:29, Dimitry Sibiryakov wrote:
> 30.10.2015 13:25, Alex Peshkoff wrote:
>> But Adriano is talking about a place for information that currently must
>> go into plugins.conf and we try to find a solution that does not require
>> editing plugins.conf when such info must be set on plugin install.
>AFAIU, Adriano said that config from default ConfigFileName is not read 
> now and his 
> plugin cannot get it.
>
I said that external plugins are not loaded without editing Firebird
supplied configuration files.


Adriano


--
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Cannot easily install plugins

2015-10-30 Thread Adriano dos Santos Fernandes
On 30/10/2015 10:53, Dimitry Sibiryakov wrote:
> 30.10.2015 13:35, Adriano dos Santos Fernandes wrote:
>> I said that external plugins are not loaded without editing Firebird
>> supplied configuration files.
>Avalerion's CDC plugin is loaded perfectly well without editing 
> plugins.conf.
>
What's the [Firebird] type of this plugin?


Adriano


--
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Cannot easily install plugins

2015-10-30 Thread Alex Peshkoff
On 10/30/2015 02:33 PM, Dimitry Sibiryakov wrote:
> 30.10.2015 12:28, Alex Peshkoff wrote:
>> 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?
> To make explicit:
>
> a) Every plugin has PluginName, ModuleName, ConfigFileName
> b) By default (without any additional editing of plugins.conf)
> ModuleName = plugins/$(PluginName).dll
> ConfigFileName = $(basename ModuleName).conf
> c) File, determined by ConfigFileName is a plain set of pairs "Option=Value".

If we talk about _INTERNAL PLUGIN_ configuration - yes, and that's how 
it works currently.
But Adriano is talking about a place for information that currently must 
go into plugins.conf and we try to find a solution that does not require 
editing plugins.conf when such info must be set on plugin install.



--
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Cannot easily install plugins

2015-10-30 Thread Alex Peshkoff
On 10/30/2015 04:00 PM, Adriano dos Santos Fernandes wrote:
> On 30/10/2015 10:57, Adriano dos Santos Fernandes wrote:
>> On 30/10/2015 10:53, Dimitry Sibiryakov wrote:
>>> 30.10.2015 13:35, Adriano dos Santos Fernandes wrote:
 I said that external plugins are not loaded without editing Firebird
 supplied configuration files.
>>> Avalerion's CDC plugin is loaded perfectly well without editing 
>>> plugins.conf.
>>>
>> What's the [Firebird] type of this plugin?
>>
> And, does it uses a .conf file through the API plugin?
>
> Of course, this is what I want, in addition to an easy-install approach,
> use the plugin's config within the Firebird plugin API.
>

Plugins can be loaded without changes in plugins.conf (the only one 
plugin which needs it is UDR, the reason is plugin name does not match 
executable module name). I suppose that after renaming libudr_engine.so 
to libUDR.so parameter
 Module = $(root)/plugins/udr_engine
will not be needed.

What about internal config values - they may be moved to 
plugins/UDR.conf which will look as follows:
path = $(root)/plugins/udr
or even better
path = $(DIR_PLUGINS)/udr

I.e. editing of plugins.conf is normally not required for plugins - UDR 
needs this (on my mind) due to historical reasons.


--
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Cannot easily install plugins

2015-10-30 Thread Dimitry Sibiryakov
30.10.2015 13:35, Adriano dos Santos Fernandes wrote:
> I said that external plugins are not loaded without editing Firebird
> supplied configuration files.

   Avalerion's CDC plugin is loaded perfectly well without editing plugins.conf.

-- 
   WBR, SD.

--
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Cannot easily install plugins

2015-10-30 Thread Alex Peshkoff
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


Re: [Firebird-devel] Cannot easily install plugins

2015-10-30 Thread Adriano dos Santos Fernandes
On 30/10/2015 11:57, Alex Peshkoff wrote:
> On 10/30/2015 04:00 PM, Adriano dos Santos Fernandes wrote:
>> On 30/10/2015 10:57, Adriano dos Santos Fernandes wrote:
>>> On 30/10/2015 10:53, Dimitry Sibiryakov wrote:
 30.10.2015 13:35, Adriano dos Santos Fernandes wrote:
> I said that external plugins are not loaded without editing Firebird
> supplied configuration files.
 Avalerion's CDC plugin is loaded perfectly well without editing 
 plugins.conf.

>>> What's the [Firebird] type of this plugin?
>>>
>> And, does it uses a .conf file through the API plugin?
>>
>> Of course, this is what I want, in addition to an easy-install approach,
>> use the plugin's config within the Firebird plugin API.
>>
> Plugins can be loaded without changes in plugins.conf (the only one 
> plugin which needs it is UDR, the reason is plugin name does not match 
> executable module name). I suppose that after renaming libudr_engine.so 
> to libUDR.so parameter
>  Module = $(root)/plugins/udr_engine
> will not be needed.
>
Well, but UDR is an "external language", it's not (necessarily) a plugin.

A plugin may have many languages and other things.

When you get the language name (from metadata) and try a file (plugin)
name, something is wrong.


Adriano


--
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


[Firebird-devel] Cannot easily install plugins

2015-10-29 Thread Adriano dos Santos Fernandes
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.


Adriano


--
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Cannot easily install plugins

2015-10-29 Thread Alex Peshkoff
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?


--
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Cannot easily install plugins

2015-10-29 Thread Dimitry Sibiryakov
29.10.2015 16:26, Adriano dos Santos Fernandes wrote:
> 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.

   It works fine for my plugin. Something should be broken in udr_engine itself.

-- 
   WBR, SD.

--
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel


Re: [Firebird-devel] Cannot easily install plugins

2015-10-29 Thread Adriano dos Santos Fernandes
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.


Adriano


--
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel