Roman Rokytskyy wrote:

>>In that case, I reject your proposal. It breaks the layering, it is
>>insufficient to scope to evaluation, and violates existing internal
>>conventions.
>>
>>
>
>You did not explain how it breaks layering - you just assume that
>handles/values are going to be obtained from Y-valve, you do not say
>why it is insufficient, you do not respond to arguments (for example
>the charset issue), and you did not care to define your internal
>conventions (Vulcan sources also do not bear a single line of
>comment) and assumes that everybody is able to read from your mind.
>
>

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.

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.

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

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

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.

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376