Roman Rokytskyy wrote:

>>
>>
>However, together with restoring layering you try to sell me are:
>
> - C++ interfaces to access the engine that were never discussed in
>that context;
>
>

Roman, you and I have been discussing this interface in this context for
at least six months now. How can you possibly say it hasn't been
discussed? We're discussing it now!

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

If they're not implemented, they should throw errors. And if they're
never implemented, they definitely should throw errors.

Firebird hasn't shown any interest in full text search. Other products
that use the interface, however, support it. If you have an objection
to the model, let's hear it.

> - guidelines for interface extension (the extension must be generic
>enough to use it in other products like OdbcJdbc driver, and possibly
>Netfrastructure).
>
>

I'm content to wait for proposals.

> - the ubiquitous Unicode usage on the API level.
>
>

More precisely, UTF-8. But yes. Do you have a problem with that?

>None of this was either discussed or accepted by the core team so far.
>And that is what I object to.
>
>

The interface has been in the ODBC driver for what? Five years? It's
been in Vulcan for almost two years. It's been fully described on the
architecture list any number of times. As best I can remember, you're
the only person who has expressed issues with it.

If you have more issues, let's hear them now.

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

Please don't do that. It's the wrong way to do it. There are better
alternatives available.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376