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*, 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 PluginModule interface (implemented by plugin) and all info
>>> about plugin should be present there. For example, we could introduce
>>> special interface to provide info about plugin, say LoadedModuleInfo,
>>> and pass it into PluginModule when PluginModule is registered at
>>> PluginManager:
>>>
>>>
>>> interface LoadedModuleInfo : Versioned
>>> {
>>> const string getModuleName();
>>> ...
>>> }
>> It should be RefCounted to be saved in module, all the rest is OK and
>> looks much better than use of ModuleInitialization in FB_PLUGIN_ENTRY_POINT
>> Moreover - due to presence of versioning schema it can be added at any
>> moment when gets needed
>>
>>> interface PluginModule : Versioned
>>> {
>>> void doClean();
>>> void setModuleInfo(LoadedModuleInfo info);
>>> }
>>>
>>> Plugin implementation could ignore passed info, store interface pointer
>>> for future use, or query all necessary info and release interface pointer.
>> So we have an agreement with adding Status to FB_PLUGIN_ENTRY_POINT, but
>> leaving Master as second parameter?
>>
>>
> No agreement with me.
>
> Current PluginModule seems to me like a workaround for destructor
> problems, now is being morphed in something else.
>
> It's currently not even required.
>
> Jaybird removed all the JNI code in favour of JNA, so the FB/Java plugin
> will load the Java code with minimal efforts and everything will be done
> in Java.
I do not see direct relationship between better way of calling native
methods from Java and a way to pass some additional info to plugin module.
> So the essential information should be in the library entry point, which
> BTW seems as the best place for it in general, instead of abuse of OOP
> and documentation to inform how to do a simple thing.
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.
------------------------------------------------------------------------------
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
