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

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

On 24-03-2011 11:45, Alex Peshkoff wrote:
>  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?
> 
The thing about "api" handles that yvalve pass to the providers to them
be able to callback yvalve before complete the API
(attach/startTransaction) call.


Adriano