Hi,

I think that the Y-valve concept is not applicable here
because we are not going to implement a Y-valve in Java.
The Y-valve in Firebird is the piece of code that makes
the routing asking to each subsystem if it can do an
attachment. In JGDS the only possible way of making an
attachment is using a TCP connection on the 3050 port so
the Y-valve idea here is useless. On the other hand, in
a future NGDS (JNI implementation) the Y-valve will be
embedded in gds32.dll and we will only do a simple wrapper
in Java. Again, the java code won't have to route anything.
IMHO, I think that we must provide a GDS API port in Java
hiding all other architectural concepts.

In all operations done against the remote Firebird server
we get a status vector. Here, we have two ways of resolving
the error handling:

1. Return that status vector to the calling applications (JDBC).

2. Convert the status vector to an exception and throw that.

IMO, I think that we must follow as close as we can the GDS
semantics and return the status vector, and let the next
layer (JDBC) to convert the status vector into a suitable
exception. I think that doing that outside of the JGDS
will provide us a closer GDS implementation allowing
us an easy porting of all kind of applications
(JDBC, IBconsole, etc).

Regards.

Alejandro Alberola
alberola@...

--- In IB-Java@y..., David Jencks <davidjencks@e...> wrote:
> I'm about to start working on some actual jdbc driver functionality
based
> on Alejandro Alberola Arias' gds implementation, and I have some perhaps
> philosophical design questions.
>
> 1. We should eventually implement a java y-valve, right? I am thinking
> that this might go well with using Catalog to indicate which database to
> connect to (maybe).
>
> 2. The current implementation appears to me to put all externally
visible
> functionality in one class, GDS[_Impl]. I am wondering if it would be a
> good idea to move the functionality that does not interact with the
Y-valve
> into other classes: then GDS would expose only functions that the
y-valve
> needs to implement, and the y-valve would have less to transfer to the
> remote interface. Obviously we will no longer be working with a straight
> java translation of the existing gds calls, but this might be fine.
Also
> the java y-valve will have the same interface as only one of the Remote
> Interface objects: the other objects don't even need to go through the y
> valve (have calls wrapped by the y valve layer), since they were
obtained
> from a connection to a particular database, they no longer need routing.
>
> 3. The current implementation, again following its c source, reports
> problems using returned error codes. I think it might be a good idea to
> replace this with exceptions.
>
> So, I'd like some opinions before I get too far along in a possibly
flawed
> approach.
>