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