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

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

 On 03/24/11 17:37, Adriano dos Santos Fernandes wrote:
> On 24-03-2011 11:23, Alex Peshkoff wrote:
>>  On 03/24/11 16:45, Adriano dos Santos Fernandes wrote:
>>> On 24-03-2011 05: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.
>>>>
>>> This is because plugins creation is currently using fixed factories,
>>> while is much better to have specific factories for specific needs.
>> Currently we have many types of plugins, and all of them work just fine
>> with fixed factories. May be as soon as you want to say - "I want
>> specific factory for some plugin" - it's time to stop and think: are you
>> doing correct things?
>>
> Just remember my proposal is not about addRef/release only.
>
> Current interface pollutes user code with internal baggage about handles.

What handles do you mean?

> Are you saying it's correct?
>

I can't say something cause I do not understand what you say....