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

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

On 28-03-2011 11:41, Alex Peshkoff wrote:
>  Adriano!
>> It's becoming difficult to discuss with you cause you change your
>> opinions everytime. Yesterday you said:
>>
>> ------------------
>>> In my new version of why.cpp things like CAttachment (C*) classes gone
>>>> in favor of YAttachment (Y*) objects. Things are much simple and
>>>> effective, became directly usable without legacy handles, may use the
>>>> same API (semantics defined in yvalve) for client and external code
>>>> running on the server.
>>>>
>> Looks like I totally agree with mentioned changes. I suppose you also
>> have a module to translate ISC API calls?
> 
> Stop! Where do you see here something like "yValve control interface"?
> I agreed with MENTIONED changes, namely:
> 
> 1. new Y* objects, usable without legacy handles.
> 2. MAY use same API for client and external code running on the server.
> 
> With this I do agree. If your new objects require yValve control
> interface - sorry, it was not MENTIONED here.
> 
Of course, as I already explained more than one times, "YObjects" are
substitutes to current C* internal yvalve objects and are what I suppose
you call "yValve control interface", otherwise would have no sense to
create them.

And as is yvalve resposability to do some things (multidb transactions
being one of them, more many things I already talked about), it's of
course better to have user using YValve objects than providers directly.

And back when Dmitry was discussing about the same things (to not use
providers directly), you were with some doubts but never was against it
nor provided a good reason to do the contrary.


Adriano