Subject Re: [Firebird-Architect] External Engines Implementation Details
Author Adriano dos Santos Fernandes
Alex Peshkov wrote:
> On Friday 28 December 2007 19:58, Jim Starkey wrote:
>> First, the exec_stmt2 impementation was a crude hack. It underlying
>> problem is that dynamic SQL wasn't available in the engine. Rather than
>> fixing that, he took a shortcut.
> Unfortunately, there was one more reasoning (don't want to say now, is it
> enough serious or not). Making yValve handles available for external engine
> lets it use our standard API. I still continue thinking that having pure
> virtual class for interface which may be filled with standard API calls (for
> debugging purporses for example) or internal engine calls is much better
> solution. But if we release external engines with current exec_stmt2
> impementation (working with yValve handles), no later DSQL/JRD merge will
> help us avoid backward compatibility problems, and we will have to keep that
> hack till the end of days. That is what seems for me the worst in exec_stmt2.
Didn't you agreed that using internal engine handles will be possible
after DSQL/JRD/Y-Valve re-architecture?

External engines is a client and should be able to use the client API,
and (unfortunately) it is currently the ISC API.