> As you see in my external engine API proposal, it creates something we
> current don't have internally. One attachment can have different
> properties depending on the context.

Is it really good and necessary ?

> For example, it can use one charset to the client and another to the
> external engine.

Why do we need such complexity ? I think we must make life of external
engine (EE) developers much easier than our ;) I mean - there is no sense
to force EE to work with all possible charset's supported by FB. At my view
two is enough - NONE (no transliteration between engine and EE) and UTF-8
(as common denominator for all charsets).

Not all applications require more than one charset to work with. Most european
and american developers may work with one-byte encoding - plain ASCII, i think.
They can use NONE (i called it fb_string_ascii in Fyracle) in most cases. All other
will work with good known UTF-8.

> It also can have user or sysdba rights.

Can you explain more on this ?

> Different charsets are also needed for future implementation of internal
> SQL, as engine SQL is expected to work with metadata (UTF-8) charset
> independently of user charset. The same for user / sysdba rights.
>
> To make it work, I need to:
> - create a REATTACH y-valve internal function
> - create the concept of "pseudo attachments"
>
> A "pseudo attachment" is resolved in DSQL and engine entry points and
> changes the real attachment properties and continues with it.* This
> seems to not be a problem for multi-thread, as multiple threads can't
> use the same attachment simultaneously. (is this simple correct?)
>
> * Dynamic properties can also live in the thread data, but this is
> enough for current implementation IMO.

Is it something like ALTER SESSION ?

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

Yes. I think when DSQL will be moved inside engine this issue will disappear

> I think these handles could be communicated to the engine via internals
> DPB/TPB.

Are you going to pass y-valve handle (or its address) via DPB/TPB ?
Or i, very probably, not understand something ?

> BTW, isn't the isc_dpb_trusted_role an internal DPB? Should not
> we create a generic mechanism for internal DPB/TPB?
>
> And yes Virginia :-), this is one more thing that violates y-valve
> layering, but it's how Firebird current works.
>
> And based on my generic API proposal, I shall be in the future proposing
> something much better than current Vulcan provider architecture, that
> also solve Vulcan problems of:
> - need more than one DLL when using embedded

Very good

> - ugly API, where engine doesn't understand client (DSQL) structures

Not sure i understand this

> - necessity of external providers understand BLR

Are you about data encoding as BLR message or something more ?

Regards,
Vlad