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

[Vlad K. <hv...@us...>]

> On 23-03-2011 13:23, Vlad Khorsun wrote:
>>>>> But this must not be done directly, since providers could be chained to
>>>>> implement things (say trace provider
>>>>
>>>> we discussed it and decided it's bad idea
>>>>
>>> You can decide it for Firebird, but you can't decide it for user. Let
>>> user create *plugins*.
>> 
>>     I believe, Alex told there about "trace provider" == "bad idea"
>> 
> I said again, he or us can't decide it's bad idea for *user*. It's
> perfect technically valid idea. It solves the problem of trace only in
> the server, just for a example.

    Then tell *explicitly* that you talk about custom user's API-tracing provider.
It is very hard to guess what do you mean here or there


>>> Code from external engines *is* external calls. May not make sense for a
>>> replay plugin, but it must pass in the yvalve too.
>> 
>>     Here is an principal point. If external code creates new attachment it is
>> certainly must go thru YValve. But if external code used current attachment -
>> why it *must* go thru YValve ?
>> 
> 
> One good reason is that yvalve is who makes legacy handles, and the
> external code *must* be accessible by *current* Firebird API too.

    Again, you could tell it few days earlyer and save a bit of our and you own time. 
 
>>>>> I propose IProviderManagement interface. The yvalve will creates an
>>>>> instance of IProviderManager and will pass it to the factory that
>>>>> creates a provider. 
>> 
>>     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. And far not 
every plugin kind needs IProviderManagement (IYvalveNotify sounds much better 
for me).

>>>> Adriano, are you serious that all described here is simpler than proxy
>>>> objects in engine? :-)
>>>>
>>> I'm *sure* it is. I showed you ~15 lines of code, against
>>> addRefs/releases around by Firebird and all-over-the-world users code.
>> 
>>     And zero lines of implementation of IProviderManagement interface :)
>> 
> Well, if I write code you say to not write code but explain ideas
> before. If I explain ideas you complain about no code...

    Write code to explain idea is not the same as write code to commit into SVN. 
And i have no idea about how do you going to implement IProviderManagement.

>>> And, BTW, it will not crash when the engine is unloaded, like I said in
>>> the another message.
>> 
>>     Why do you think engine could be unloaded if not all references are released ?
>> 
> Ah, another set of refcounting to prevent it to unload when only proxies
> exists...

    Why not ? This is another useful example of using refcounting ;)

Regards,
Vlad