> I have explained the handle issue over and over until I was blue in
> the face. Did you not see the long post on transmission layers and
> handle encapsulation? Do you think I wrote that for my personal
> edification? I have been trying to explain to you why what you
> naively dismiss as a trivial problem is a show stopper.

No, but you have missed the point that me and Vlad tried to explain,
that we are not bound to use external handles. It is so now, but also
you agree that handle is just 32-bit number. So, if the API for
external procedures is below the Y-valve, then it uses those handles
that are available on that level.

> I did respond to your question of character set. To recap, strings
> across the IscDbc (Connection) interface are UTF-8, though this
> isn't yet implemented.

I was not talking about that question. Please read the post to which
you replied with "I reject" phrase - there is my question asking why
the client has to handle UTF-8.

> Did I miss a question on internal conventions? Ask and I'll
> explain.

No, you didn't. You just stated that proposal breaks the internal
conventions without stating which and how.

> I think integration of a Java Virtual Machine is one of the more
> important single projects in Firebird's future. A high quality,
> tight integration of a highly expressive, object oriented language
> makes all sort of extensibility possible without sacrifice of engine
> integrity.

You have failed to see that there are a lot of people that do not care
about Java. There is already engine with integrated JVM called
Netfrastructure but it does not solve the tasks people have when they
run in pure Windows environment. It solves the web development issues
but is no help to people that want to do PHP instead of your templating.

> To make this possible, I spent a good month building a squeaky
> clean, JDBC compliant, internal interface to both export engine
> semantics to external services and to form the basis for the native
> component of an internal JDBC implementation. Does it bother me
> that you have rejected it out of hand in favor of a bastardized
> interface faithful to nothing?
> You bet!

Well, that was your private project with the same rights to live as
current implementation of Java procedures. You did not discuss this
issue with anybody (at least I do not remember that discussion) from
the Firebird project when implementing it in the Vulcan.

> I suggest you go back to the drawing board with the assumption that
> you have an abstract set of C++ classes that export JDBC semantic
> that you can exploit. Your job with be easier and the net result
> will be better.

We do not have those classes in Firebird. We have them in Vulcan and I
have not seen single discussion whether they remain there or not,
whether people want those interfaces or not and so on.

Roman