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

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

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.

>>>> , log/replay provider
>>>
>>> which must log only external calls
>>>
>> 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.

>>>> 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.

> ...
>>> 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...

>> 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...


Adriano