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, &factory);
>> (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.
------------------------------------------------------------------------------
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
