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 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 factory and do all the work lazily. What the >>>> problem you are going to address ? >>>> >>>> >>> And that can be answered in one go: the engine already lazily load plugins. >> And what ? I still not understand you >> >>> Why would my plugin will have MT code to load a JVM, since its only job >>> when the engine loaded it, and I can have a simple code doing that? >> I don't know. I still see no problem you are trying to solve. >> >>> Also, it's a good design to let code report errors and the plugin >>> initialization cannot do it. >> 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. Why would you will > limit us forever if more types of plugins can exist in the future. > > That remembers me the intl library. You can do nothing on it because the > design didn't anticipated extensions. > 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. The engine already knows the filename it's loading, it could pass it. it could libe in IPluginInitialization. Adriano ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
