Re: [Firebird-devel] Providers, yvalve, external engines and object lifecycle

[Alex P. <pes...@ma...>]

 On 03/24/11 11:33, Vlad Khorsun wrote:
>>>> How it could be done ? How YValve knows about *provider's* factories ?
>>>> It's yvalve who instantiates plugins.
>>> Really ? I thought it is PluginManger, who instantiates plugins.
>> I recall an agreement here that PluginManager should be a part of the y-valve, not the engine. Perhaps it's already linked this 
>> way, I haven't checked. So I believe Adriano is talking about the y-valve as a library, not as just why.cpp.
>     YValve asks PluginManager to instantiate Providers. But plugns is much more wide than just
> Providers. And PluginManager is responsible to instantiate all kinds of plugins. And far not all of
> plugins need callbacks into YValve.

Guys!
Looks like currently we call 2 different things with same name yvalve -
it's provider's dispatcher (yValve in original understanding) and
fbclient library. Suppose this is partially due to badly selected by me
name for a directory - src/yvalve. Currently in this directory all
external entrypoints if our API are collected, though central part of
this is yvalve itself.

PluginManager is also a part of that library. And certainly, it's
relatively simple to add some additional call from why.cpp to
PluginManager. But not any thing, which may be easy done, should be
done. Adding additional, absolutely unrelated with overall plugins
schema functionality, due to desire to make additional channel for
single type of plugins is wrong solution.