|Subject||Re: [Firebird-Architect] External Engines Implementation Details|
> As you see in my external engine API proposal, it creates something weIs it really good and necessary ?
> current don't have internally. One attachment can have different
> properties depending on the context.
> For example, it can use one charset to the client and another to theWhy do we need such complexity ? I think we must make life of external
> external engine.
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 internalIs it something like ALTER SESSION ?
> 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.
> I also need to communicate y-valve handles to engine, as Vlad does inYes. I think when DSQL will be moved inside engine this issue will disappear
> exec. stmt branch. But the solution Vlad is using doesn't work with
> CONNECT and TRANSACTION START triggers, as he said.
> I think these handles could be communicated to the engine via internalsAre 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 notVery good
> 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
> - ugly API, where engine doesn't understand client (DSQL) structuresNot sure i understand this
> - necessity of external providers understand BLRAre you about data encoding as BLR message or something more ?