Vlad Khorsun escreveu:

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

Yes. In External Engine, there may be two logical connection types.

One is for the Engine itself manage metadata. Not all engines is dumb,
they need to inspect metadata to load things (example: .class file
stored in blob). And planning security from the start, such type of
information should not be available to users. This logical connection
generally can work with UTF-8 and should have SYSDBA rights.

Another connection type is the one to execute
functions/procedures/triggers. This one needs user rights. And we can't
guess the charset they want. Also, it's another client, running in
different environment from the user, so user charset should not
interfere with it.

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

I don't think your argument is correct. This "complexity" makes our
(engine developers) live a bit less-easier. EE developers can just pass
a charset name.

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

This may be true only in managed (JVM / .NET) environments. I don't
think we should break all INTL concept of transliteration and client
charset for nothing.

>
>> It also can have user or sysdba rights.
>>
>
> Can you explain more on this ?
>

Already explained above... For EE metadata handling. And also, this is
required for future internal SQL metadata handling.

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

Not exactly.

For user, it's more like two attachments.

For engine, only entry points functions understand the pseudo
attachment, transforms it to real attachment. For monitoring purposes,
there is only one attachment.

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

This solve the problem with database triggers.

> Or i, very probably, not understand something ?
>

Since it's from y-valve to internal engine, I see no problem except
establish a generic DPB/TPB mechanism for this.

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

Vulcan Engine8 class can handle only BLR messages, and Dispatcher can
handle DSQL structures. Both are derived from Subsystem that implements
both ways throwing error.

It's very bad designed.

>
>> - necessity of external providers understand BLR
>>
>
> Are you about data encoding as BLR message or something more ?

Yes. Providers should not need to do this.


Adriano