Re: [Firebird-devel] Plugins and providers

[Adriano d. S. F. <adr...@gm...>]

On 21/10/2010 06:44, Alex Peshkoff wrote:
> It has big bad problem - plugins can't work without configuration files.

And what? Firebird can't work without config file too.

Do you wanna the not-explained approach of less-files/happy-users? 
Embedded the default config files in the library them.

> And that configuration files look definitely overcomplicated - as a
> sample let's look at udr_engine.conf:
>
> external_engine = UDR {
>          plugin_module = UDR_engine
> }
> plugin_module = UDR_engine {
>          filename = $(this)/udr_engine
>          plugin_config = UDR_config
> }
> plugin_config = UDR_config {
>          path = $(this)/udr
> }
>
> All this is written to make plugin manager look for first for
> udr_engine.conf (instead directly for libudr_engine.so or
> udr_engine.dll) and use as a source of engines for that plugin directory
> udr!

And what we had for the Java plugin?

A .conf file dropped in <fbroot/plugins>, just including the plugin main 
directory living in another tree.

Your approach is based on copy-files. It's difficult to develop plugins. 
It's awful for deployment.

>   I.e. this configuration files configures actually _nothing_ - it's
> just a waste of disk space and CPU cycles :-)
See above, you're nothing seeing the big picture. You're seeing the 
small picture of plugins for Firebird internal needs. This is not plugins!

>   And what is worse - it's a
> waste of users' time trying to understand why was it written at all. And
> last is already not a joke.
>
In my opinion, a default config file with real configuration is better 
than firebird.conf, with list everything commented and has default in 
the code.

> I do not want to talk here about fbintl.conf. It's also awful and not
> needed, but I think we can leave it as is with it's legacy interface. At
> least in version 3.

As I said, it was discussed 6 years ago by me and Nickolay in ICQ and 
proposal sent and approved in fbarchitect.

>> Second one uses
>> cryptic things like template parameters<100>,<200>  in the code.
> Absolutely agreed - bad. And therefore planned for removal.
>> First one was discussed about 6 years ago. Second one was never
>> discussed, so it's difficult to understand and comment about it.
> Sorry, that discussion ended with nothing. There was no agreement.
> Must say that COM-like format for plugins and providers was discussed by
> me, Vlad and Dmitry at the conference in Moscow. And at least we 3 had a
> kind of agreement.

And COM-like plugin I introduced say, 2 years ago for the external 
engines, with a lot of more discussions. But now is just another ignored 
and remade part. It seems you understood it as a server-only facility, 
with it was used for, but was never in its roots.

>> For *plugin* I understand as ability to third party developers extend
>> the server, and when well done, would allow the Firebird code as well to
>> be plugable.
> Certainly.
>> If plugin is thought only as a Firebird internal need or that the third
>> party developer would need to download full Firebird sources to compile
>> they "plugins", then we'll not be talking about plugins.
> I agree that this is very good idea to pass plugin's configuration from
> plugin manager - just to make plugins creation simpler, not repeat same
> code, etc. What about suggested interface - it does not have any
> restrictions on how is plugin written: from this POV it's exact COM.
>

> Autoloader might be very good (specially for client-side plugins), but
> it has one very bad problem - it can't be said something about plugin
> (name, kind and specially order of invitation) without loading module.
> Why it's bad is specially well seen on the sample of providers. When
> trying to open any database we must first of all load all providers,
> cause without it we do not know in what order they should be tried. And
> order is very important here to distinguish between embedded and
> implicit localhost connections using loopback provider.
>
> I suggest to use an approach with minimum configuration (nothing to be
> done in default case), but with an ability to have as complex
> configuration as required when it's really required.
>
I prefer to embed config files in our libraries and allow them to be 
overridden or extended using files.

> As a base for loading plugins into firebird we use existing plugins
> manager, but:
> - make it work with COM-like interfaces;
Please explain. BSTRs? IDL files? Windows only? Just query-interface 
like, pure-virtual functions and dispose method?

> - move it to yValve from engine;
> - add public API support for both registering plugins in it and querying
> about known plugins;
> - remove unneeded configuration dependencies;
> - make list of plugins configurable from firebird.conf with intelligence
> (probably platform-dependent) defaults.
>
The approved solution 6 years ago was to had firebird.conf including 
another config files. Everything separated. Please, don't make plugin 
developers need to change firebird.conf!

> Last point requires some comments. For each type of plugin (provider,
> external engine, etc.) we have appropriate parameter in firebird.conf
> with some default value. I.e.
>
> #Provider = remote, engine12, loopback
> #ExternalEngine = udr_engine
>
Why dependencies can't be satisfied as plugins load and request another 
plugins?

> Please pay attention - in default case external module contains single
> plugin and this file name == plugin name. This makes all configuration
> in files like udr_engine.conf not needed at all. What about path =
> $(this)/udr - about such defaults plugin must know itself.
The default is there in the .conf file, just uncommented, differently 
from firebird.conf. You don't need to edit, or even open the file. It 
just works.

>   But certainly
> if we need to pass something useful to plugin - file $(plugin name).conf
> exists and contains that data. But I see no need in putting what is
> passed to plugin inside plugin_config group - let it be just a plane
> list of parameters. Moreover, in case when module name is not same as
> plugin name, parameter ModuleName is present in that same list. May be
> not structured, but clear for users.
>
> When non-default set of plugins should be loaded, appropriate parameter
> must be provided in firebird.conf (or aliases.conf when it makes sense).
> Sample in aliases.conf:
>
> olddb = /path/to/that/old/database.gdb
> {
>      Provider = gateway11    # loads embedded library from 2.5
> }
>
I disagree on putting plugin config in firebird.conf.


Adriano