Subject Re: [Firebird-Architect] Re: Java Stored Procedures
Author Jim Starkey
Roman Rokytskyy wrote:

>Maybe... but only if that someone would like to stay with JDBC 1.2,
>but considering JDBC 4.0 to be released next year... I know how much
>code in JayBird is responsible for JDBC compatibility, and what does
>it mean to be JDBC-compatible.
>
>
No, it doesn't mean that. It only means that the functionality
available in Firebird can be captured in JDBC 1.2. It can be extended,
but it doesn't have to be.

>And you did not answer how tiny that layer would be for other
>components, like IBX/FIB/IBO for those willing to code in Delphi, or
>.Net with their ADO component model.
>
>
Huh? We were talking about an internal engine API exportable to
language processors. What does that have to do with IBX, et al?

>
>
>And regarding to the calls, it is definitely more informational than
>version strings. Unfortunately you cannot rewind the history and add
>them to Firebird 1.0 and 1.5, so version string have to be supported.
>
>
Nobody has suggested that the load language processor interface be
backported to Firebird 1.0 or 1.5, so I don't see your point.

>
>
>As you suggested, the "API" object will be passed into the call. In
>your case its InternalConnection, in case of ISC API some db handle
>and tr handle would be enough.
>
>
Roman, the external API doesn't exist inside the engine in a supportable
manner. Just get used to that idea.

>
>
>>The problem is that the current ISC API is soon to be relegated to a
>>client side layer on top of a more efficient API. Much of what you
>>consider the current API disappears inside of the client side
>>Y-valve and isn't supported in the engine at all. Building in the
>>old SQLDA-based interface makes no sense at all.
>>
>>
>
>Well. When it disappers, I will adopt a new API, but so far I do not
>feel to be an early adopter for something that would need complete
>rewrite of JayBird.
>
>
Let us get this straight. You want to screw up the internal
architecture of Firebird so you don't have to change your code. Is that
the only real issue here?


--

Jim Starkey
Netfrastructure, Inc.
978 526-1376