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

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

 On 03/24/11 17:51, Adriano dos Santos Fernandes wrote:
> 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.

May be you have forgotten - one of my proposals is to not pass external
handles in attach/startTransaction call. And do not pass them into
engine in any way. Cause with new API we have much better way to access
current context.