On 11/16/2015 05:26 PM, Daniel Rail wrote:
> Hi,
>
> At November 15, 2015, 9:22 AM, Alex Peshkoff wrote:
>
>>> I
>>> see discussions about details but I can't find a basic architecture
>>> description, maybe I'm missing some obvious documents?
>> There is doc/README.plugins.html but it's very far f
Hi,
At November 15, 2015, 9:22 AM, Alex Peshkoff wrote:
>> I
>> see discussions about details but I can't find a basic architecture
>> description, maybe I'm missing some obvious documents?
> There is doc/README.plugins.html but it's very far from ideal. Like
> unfortunately a lot of our docume
15.11.2015 17:40, Alex Peshkoff wrote:
>> Ok, but you said that every reload of databases.conf will lead to
>> creating of a new
>> >config object instance, right? Why?
> Certainly it's implementation detail, but I've wrote that code and for
> me it's the easiest way to support per-DB configu
On 11/15/2015 07:23 PM, Dimitry Sibiryakov wrote:
> 15.11.2015 16:53, Alex Peshkoff wrote:
>> On 11/15/2015 06:25 PM, Dimitry Sibiryakov wrote:
15.11.2015 14:22, Alex Peshkoff wrote:
>> Use of permanent
>> interface is not an option here - configuration for module may change
>>
15.11.2015 16:53, Alex Peshkoff wrote:
> On 11/15/2015 06:25 PM, Dimitry Sibiryakov wrote:
>> >15.11.2015 14:22, Alex Peshkoff wrote:
>>> >>Use of permanent
>>> >>interface is not an option here - configuration for module may change
>>> >>during server lifetime, and creating new and new permane
On 11/15/2015 06:25 PM, Dimitry Sibiryakov wrote:
> 15.11.2015 14:22, Alex Peshkoff wrote:
>>Use of permanent
>> interface is not an option here - configuration for module may change
>> during server lifetime, and creating new and new permanent instances
>> means memory leak.
> Here you imp
15.11.2015 14:22, Alex Peshkoff wrote:
> Use of permanent
> interface is not an option here - configuration for module may change
> during server lifetime, and creating new and new permanent instances
> means memory leak.
Here you imply that plugin must see configuration files in state they w
On 11/14/2015 05:47 AM, Claudio Valderrama C. wrote:
>> -Original Message-
>> From: Alex Peshkoff [mailto:[email protected]]
>> Sent: Viernes, 13 de Noviembre de 2015 7:25
>>
>> On 11/13/2015 01:17 PM, Vlad Khorsun wrote:
>>> interface LoadedModuleInfo : Versioned
>>> {
>>> const string
14.11.2015 3:47, Claudio Valderrama C. wrote:
> can I ask naively why the thing needs to be so complex and now it has to be
> RefCounted, too? Is this a kind of functionality that will be used only by
> the core developers? In this case, it can be as complex as one wishes if
> this makes FB more ob
> -Original Message-
> From: Alex Peshkoff [mailto:[email protected]]
> Sent: Viernes, 13 de Noviembre de 2015 7:25
>
> On 11/13/2015 01:17 PM, Vlad Khorsun wrote:
> >
> > interface LoadedModuleInfo : Versioned
> > {
> > const string getModuleName();
> > ...
> > }
>
> It should be Ref
13.11.2015 12:43, Alex Peshkoff wrote:
> Performing long jobs in module startup entry point is not good from at
> least one POV - plugin manager mutex is locked at this moment and all
> other plugins related activity is impossible.
So, it would be enough not to use plugin manager with mutex, no
13.11.2015 11:25, Alex Peshkoff wrote:
> So we have an agreement with adding Status to FB_PLUGIN_ENTRY_POINT, but
> leaving Master as second parameter?
Have you noticed, that plugin entry point become more and more like
IFactory::createPlugin()?..
--
WBR, SD.
12.11.2015 23:24, Vlad Khorsun wrote:
> 13.11.2015 0:02, Dimitry Sibiryakov wrote:
>> >12.11.2015 22:30, Vlad Khorsun wrote:
>>> Yep. As I said, good old style plugins: separate library for
>>> each, a definite entry
> point for each type which returns ready-to-use plugin c
On 11/13/2015 01:37 PM, Adriano dos Santos Fernandes wrote:
> On 13/11/2015 08:25, Alex Peshkoff wrote:
>> On 11/13/2015 01:17 PM, Vlad Khorsun wrote:
>>> 13.11.2015 11:21, Alex Peshkoff wrote:
>>>
> So the prototype will become:
>
> void FB_PLUGIN_ENTRY_POINT(IStatus*, IPluginInitializ
On 13/11/2015 08:25, Alex Peshkoff wrote:
> On 11/13/2015 01:17 PM, Vlad Khorsun wrote:
>> 13.11.2015 11:21, Alex Peshkoff wrote:
>>
So the prototype will become:
void FB_PLUGIN_ENTRY_POINT(IStatus*, IPluginInitialization*);
>>> OK, let's pass here more generic interface. Though curr
13.11.2015 12:25, Alex Peshkoff wrote:
...
> So we have an agreement with adding Status to FB_PLUGIN_ENTRY_POINT, but
> leaving Master as second parameter?
Yes, as for me.
Regards,
Vlad
--
Firebird-Devel mailing lis
On 11/13/2015 01:17 PM, Vlad Khorsun wrote:
> 13.11.2015 11:21, Alex Peshkoff wrote:
>
>>> So the prototype will become:
>>>
>>> void FB_PLUGIN_ENTRY_POINT(IStatus*, IPluginInitialization*);
>> OK, let's pass here more generic interface. Though currently I do not
>> see something except getMaster()
13.11.2015 11:21, Alex Peshkoff wrote:
>> So the prototype will become:
>>
>> void FB_PLUGIN_ENTRY_POINT(IStatus*, IPluginInitialization*);
>
> OK, let's pass here more generic interface. Though currently I do not
> see something except getMaster() in it - let's be generic.
There is PluginModu
On 11/13/2015 12:57 PM, Vlad Khorsun wrote:
> 13.11.2015 11:45, Adriano dos Santos Fernandes wrote:
>> On 12/11/2015 17:18, Vlad Khorsun wrote:
>>> 12.11.2015 20:24, Adriano dos Santos Fernandes wrote:
>>> ...
BTW, another info the plugin entry point could receive now: the library
filenam
13.11.2015 11:45, Adriano dos Santos Fernandes wrote:
> On 12/11/2015 17:18, Vlad Khorsun wrote:
>> 12.11.2015 20:24, Adriano dos Santos Fernandes wrote:
>> ...
>>> BTW, another info the plugin entry point could receive now: the library
>>> filename.
>>>
>>> This way it can load additional configur
On 12/11/2015 17:18, Vlad Khorsun wrote:
> 12.11.2015 20:24, Adriano dos Santos Fernandes wrote:
> ...
>> BTW, another info the plugin entry point could receive now: the library
>> filename.
>>
>> This way it can load additional configuration files, for example.
>>
>> That can be obtained by it him
13.11.2015 11:21, Alex Peshkoff wrote:
>> Maybe they should be returned to the user, and a method to log things is
>> also necessary, but that probably should live in IMaster/IUtil
>
> Yes. We need an analogue of gds__log in IUtil.
Please. We need dedicated interface for logging and implementa
On 11/12/2015 06:20 PM, Adriano dos Santos Fernandes wrote:
> Hi!
>
> Currently plugin entry points receives just an IMaster.
>
> It cannot do much things with only this.
>
> Not all plugins will register a factory and do all the work lazily.
If plugin does not register a factory error loading it
13.11.2015 0:02, Dimitry Sibiryakov wrote:
> 12.11.2015 22:30, Vlad Khorsun wrote:
>>> Yep. As I said, good old style plugins: separate library for each, a
>>> definite entry
point for each type which returns ready-to-use plugin class instead of
pointless factory.
>> I see no
12.11.2015 22:30, Vlad Khorsun wrote:
>> Yep. As I said, good old style plugins: separate library for each, a
>> definite entry
>> >point for each type which returns ready-to-use plugin class instead of
>> >pointless factory.
> I see no good reason to force people to isolate tightly coup
12.11.2015 21:33, Dimitry Sibiryakov wrote:
> 12.11.2015 20:12, Vlad Khorsun wrote:
>> How much ? Do yo know way better ?
>
> Not much, I agree. But still it is excess.
>
>> Do yo know way better ?
>
> Yep. As I said, good old style plugins: separate library for each, a
> definite e
12.11.2015 20:12, Vlad Khorsun wrote:
> How much ? Do yo know way better ?
Not much, I agree. But still it is excess.
> Do yo know way better ?
Yep. As I said, good old style plugins: separate library for each, a
definite entry
point for each type which returns ready-to-use plugin c
12.11.2015 19:57, Adriano dos Santos Fernandes wrote:
> Not only config file, the FB/Java plugin needs a *.jar directory.
You can put "JarDirecory=c:\whatever\" into you plugin's config.
> The design choose by Firebird code is that defaults does not need to be
> listed in the config file. It's
12.11.2015 20:24, Adriano dos Santos Fernandes wrote:
...
> BTW, another info the plugin entry point could receive now: the library
> filename.
>
> This way it can load additional configuration files, for example.
>
> That can be obtained by it himself, but it's trick, it's platform dependent.
12.11.2015 20:14, Dimitry Sibiryakov wrote:
> 12.11.2015 19:07, Vlad Khorsun wrote:
>> And what a problem do you see there ?
>
> None. Just some unnecessary work and pollution of internal tables.
How much ? Do yo know way better ?
...
>> Plugin Manager is a component of fbclient
On 12/11/2015 16:44, Dimitry Sibiryakov wrote:
> 12.11.2015 19:24, Adriano dos Santos Fernandes wrote:
>> BTW, another info the plugin entry point could receive now: the library
>> filename.
>>
>> This way it can load additional configuration files, for example.
>It already can be done with ICo
12.11.2015 19:24, Adriano dos Santos Fernandes wrote:
> BTW, another info the plugin entry point could receive now: the library
> filename.
>
> This way it can load additional configuration files, for example.
It already can be done with IConfig that provides access to all
configuration a plug
12.11.2015 20:19, Adriano dos Santos Fernandes wrote:
> On 12/11/2015 15:35, Vlad Khorsun wrote:
...
>> I have no objection to add IStatus to the FB_PLUGIN_ENTRY_POINT.
>>
>> But i see no need in IPluginInitialization.
>
> IPluginInitialization is a way to make things extensible.
How ??
On 12/11/2015 16:19, Adriano dos Santos Fernandes wrote:
> On 12/11/2015 15:35, Vlad Khorsun wrote:
>> 12.11.2015 19:19, Adriano dos Santos Fernandes wrote:
>>> On 12/11/2015 14:51, Vlad Khorsun wrote:
12.11.2015 17:20, Adriano dos Santos Fernandes wrote:
> Hi!
>
> Currently plugin
On 12/11/2015 15:35, Vlad Khorsun wrote:
> 12.11.2015 19:19, Adriano dos Santos Fernandes wrote:
>> On 12/11/2015 14:51, Vlad Khorsun wrote:
>>> 12.11.2015 17:20, Adriano dos Santos Fernandes wrote:
Hi!
Currently plugin entry points receives just an IMaster.
It cannot do mu
12.11.2015 19:07, Vlad Khorsun wrote:
> And what a problem do you see there ?
None. Just some unnecessary work and pollution of internal tables.
> If you think you see a problem - report it.
Already done privately to Alex.
> Plugin Manager is a component of fbclient, Dispatche
12.11.2015 19:51, Dimitry Sibiryakov wrote:
> 12.11.2015 18:37, Vlad Khorsun wrote:
>> Plugin manager (not the engine itself) used list of plugins of given
>> kind which is configured
>> in firebird.conf
>
> Right. But when their modules are loaded, they register all plugins they
> imple
12.11.2015 18:37, Vlad Khorsun wrote:
> Plugin manager (not the engine itself) used list of plugins of given kind
> which is configured
> in firebird.conf
Right. But when their modules are loaded, they register all plugins they
implements,
even those that are not needed.
Next, for Key
12.11.2015 19:25, Dimitry Sibiryakov wrote:
> 12.11.2015 18:19, Adriano dos Santos Fernandes wrote:
>> And that can be answered in one go: the engine already lazily load plugins.
>
> It is not quite so, plugins are loaded by engine even if they are not
> needed, because
> engine cannot predict
12.11.2015 19:19, Adriano dos Santos Fernandes wrote:
> On 12/11/2015 14:51, Vlad Khorsun wrote:
>> 12.11.2015 17:20, Adriano dos Santos Fernandes wrote:
>>> Hi!
>>>
>>> Currently plugin entry points receives just an IMaster.
>>>
>>> It cannot do much things with only this.
>> Example ?
>>
>>>
12.11.2015 18:19, Adriano dos Santos Fernandes wrote:
> And that can be answered in one go: the engine already lazily load plugins.
It is not quite so, plugins are loaded by engine even if they are not
needed, because
engine cannot predict which one will register required plugin afterward.
On 12/11/2015 14:51, Vlad Khorsun wrote:
> 12.11.2015 17:20, Adriano dos Santos Fernandes wrote:
>> Hi!
>>
>> Currently plugin entry points receives just an IMaster.
>>
>> It cannot do much things with only this.
>Example ?
>
>> Not all plugins will register a factory
>Why ?
>
>> and do all
12.11.2015 17:20, Adriano dos Santos Fernandes wrote:
> Hi!
>
> Currently plugin entry points receives just an IMaster.
>
> It cannot do much things with only this.
Example ?
> Not all plugins will register a factory
Why ?
> and do all the work lazily.
I see no problem to create facto
12.11.2015 16:20, Adriano dos Santos Fernandes wrote:
> So the prototype will become:
>
> void FB_PLUGIN_ENTRY_POINT(IStatus*, IPluginInitialization*);
Take a step further:
a) Use separate entry points for separate plugin types.
b) Drop factory, let entry point to return plugin itself.
c) Drop
Hi!
Currently plugin entry points receives just an IMaster.
It cannot do much things with only this.
Not all plugins will register a factory and do all the work lazily.
It should receive a "plugin config" parameter and an Status to report
errors to the engine, to log them or return to the user.
45 matches
Mail list logo
