"Jim Starkey" ...

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

Handle issue exists only because DSQL wrong layering. Move DSQL into
engine (as you did in Vulcan) and there are no handle issue. Hack used by
'execute statement' will be supported in FB 2.

> I have been trying to explain to you why what you naively dismiss as a
> trivial problem is a show stopper.

Sorry i don't see such bug problem as show stopper. Roman's proposition
don't depend on our problems with DSQL and\or handles. External engine mostly
act's as usual client which used public API (isc_XXX). Difference is how it
obtain
API entrypoints (not from fbclient.dll but from the engine at load time) and
from
where it get 'current' attachment and transaction handles. External engine get
it
from the engine by special written call, but only engine know from where this
handles are going. So - proposition itself has nothing as bad as show stopper.

...

> I think integration of a Java Virtual Machine is one of the more
> important single projects in Firebird's future. A high quality, tight

You overestimate it importance. Personally i much more want to see
performance monitoring, crossdatabase queries and richer SQL but this
is only me

> integration of a highly expressive, object oriented language makes all
> sort of extensibility possible without sacrifice of engine integrity.

Nobody here want to 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?

Who has decided that old ISC API will go away ? There are tons of components
used this API. Even if you release shine new Jdbc-like API tomorrow - nobody
will use it at least year. Nobody want to write engine extensions without first
debugging it as usual application. Yes - Jdbc is 'native' interface for Java ,
but
Java is not only environment on earth. And Java developers is not a bigger part
of Firebird users, i believe. I have nothing against Java itself...

Regards,
Vlad

PS I still not seen your comments about ErrorObject. I hope you don't call it
'another show stopper' ;)