|Subject||Re: Java Stored Procedures|
> Interfaces are extensible. If we need to extend it, we extend it.See below.
> No matter what API is defined, code with have to written to make anyNot compatibility, but letting people to work with the components they
> language processor work with the engine and use that API. As for
> target code, since there currently any Firebird procedure code
> written in Delphi, C++, or Java, compatibility isn't a factor.
are used to.
> The Connection interface is the internal SQL API and is layered onAs I said, if after merge Connection interface becomes the official
> CStatement, the engine compiled SQL class. Writing another API that
> supports SQL is a huge amount of work, and given that the FB2 guys
> have zero interest in using SQL internally, the chances of another
> interface are mighty slim.
internal API, I will think what to do next - wrap it with ISC-like API
to simplify the life, or to rewrite parts of JayBird to fit into the
picture, and please be sure that I will check the performance and
maintainability benefits of both solutions. If not, I will think about
the new interface.
> You've made two objections: 1) it has stuff you don't need, and 2)Jim, I never objected the fact that layering should be restored and I
> it doesn't have other stuff that you don't need. I don't consider
> either as even marginally serious arguments. I have given you the
> reasons that you can't call internal functions and why the external
> API can't be used without breaking the layering now and can't be
> used at all with Vulcan and future versions.
do not object to something that I do not need but it is useful for
However, together with restoring layering you try to sell me are:
- C++ interfaces to access the engine that were never discussed in
- compatibility constraints for them (like full-text seach API from
Netfrastructure which was never discussed and calls currently throw
errors, since they are not implemented);
- guidelines for interface extension (the extension must be generic
enough to use it in other products like OdbcJdbc driver, and possibly
- the ubiquitous Unicode usage on the API level.
None of this was either discussed or accepted by the core team so far.
And that is what I object to.
And for now, in order not to screw things up in the engine I simply
stick to what I have, basically the ISC-like API.