Alex Peshkov escreveu:

> On Thursday 27 December 2007 19:17, Jim Starkey wrote:
>
>> Adriano dos Santos Fernandes wrote:
>>
>>> I also need to communicate y-valve handles to engine, as Vlad does in
>>> exec. stmt branch. But the solution Vlad is using doesn't work with
>>> CONNECT and TRANSACTION START triggers, as he said.
>>>
>
> What do you mean here? There is no new conection and no new transaction. How
> are triggers related with it?
>

User attach to database, connection trigger is executed and call an
external function that want to access the database.
This will not work.

>
>>> I think these handles could be communicated to the engine via internals
>>> DPB/TPB. BTW, isn't the isc_dpb_trusted_role an internal DPB? Should not
>>> we create a generic mechanism for internal DPB/TPB?
>>>
>
> Generic mechanism is too loud word for very simple thing - removing a set of
> tags from parameters block in remote listener. As soon as we start to talk
> about embedded access word 'internal' looses any sense.
>

I'm not sure if this is correct after the recent changes related to
trusted auth.

If an external function tries to attach to another database direct by
the engine provider, can't it access this database with elevated (from
user POV) rights?

It may be good to know how trusted auth. is going to work with external
engines and "data links" (as Vlad documented something about trusted
auth. being used there).

>
>>> And yes Virginia :-), this is one more thing that violates y-valve
>>> layering, but it's how Firebird current works.
>>>
>> Let me say that you are making a very serious mistake that Firebird
>> developers will regret for years to come and leave it at that.
>>
>
> I'm completely agreed with Jim here.
> Instead of thinking how to violate providers architecture

Main objective is not break the "providers architecture".

But let's realize that what Jim planned more than 20 years ago were not
implemented the way he wants. Period.

We have three layers of code (y-valve, dsql, jrd) with very bad
integration, that can be extended for new features and (as always) I
propose things trying to thinking in future development.

> may be it's better to discuss how to implement new features, not breaking it?

What it breaks, please? The architecture?

Maybe we can starting fixing from EXECUTE STATEMENT? :-)


Adriano