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

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

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

>>> , 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 ?

>> I think that for current attachment (and transaction) external engines
>> must directly use appropriate engine interfaces.
>> Same for transactions created internally.
>> 
> No, please. Let create good and unified thing, not a lot of specific
> thing because we don't want to think.

    Sorry, but this is just a few worlds. I see no good technical reasons behind it.

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

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

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

Regards,
Vlad