Hi Jim & others.

Thanks for quibbling.

And your right engine is the wrong word.

And just checking, the Y-value switch stuff is basically in jrd/why.c, as
I understand it

What I am sugesting is implementing a similar interface to the Y-Value within
the jdbc client. but using a java interface and different classes that
implement that interface. Locally the jdbc client could hold a collection
of them. This as I understand is similar to how Y-value switch works.

So:

Application
-----
DBXXXConnectionInterface
-----
with three seperate potential implementations (names for examples only)
(DBXXXRemoteConnection,
DBXXXLocalConnection,
DBXXXInterserverConnection

This in the jdbc client I would see acting much the same as Y-Value currenly
does in the C client.

The "LocalConnection" type 2 guy since it goes through the existing C sql
interface would additionally go through the C Y-Value layer to determine if
it was really local or connecitng remotely.



If calling the type 4 RemoteConnection then we would have

Application (java)
----------------
Jdbc (java)
----------------
ConnectionInterface (RemoteConnection) (java)
----------------
(line protocol)
----------------
Remote server
----------------
Y-Valve
----------------
Engine


If calling a type 2 LocalConnection - but a remote database specification it
would have

Application (java)
----------------
Jdbc (java)
----------------
ConnectionInterface (LocalConnection) (java)
----------------
jni layer (c)
----------------
Y-Valve (c)
----------------
Remote interface (c)
----------------
(line protocol)
----------------
Remote server (c)
----------------
Y-Valve (c)
----------------
Engine (c)



If calling a type 2 LocalConnection - and now a local database specification
it would have

Application (java)
----------------
Jdbc (java)
----------------
ConnectionInterface (LocalConnection) (java)
----------------
jni layer (c)
----------------
Y-Valve (c)
----------------
Engine (c)


The type 3 itnerclient approach I won't bother describing but the picture
should be clear.


In the naming, of XXX, WHY doesn't seem to cut it, but I suppose it could be
Service/Firebird/GDS any suggestions?

DBXXXConnectionInterface,
DBXXXRemoteConnection,
DBXXXLocalConnection,
DBXXXInterserverConnection

Since Im currently tied up in main Firebird stuff Im not going to be
contributing much initially here ( but I will be watching with interest) So
Im happy to leave it up to those who are going to do it to determine the what
directory structure and file names they want to follow, but your right it was
certainly worth clarifying, and I hope my recasting the proposal into your
structure help clarrify what I was thinking about.

On a final note, one thing I can see c++ adding is providing a cleaner way to
implement the currenty why.c procedures with abstract base and concrete
implementation classes or each type. But thats a little down the track.

It would be interesting to see how isc4.gdb fits into the why structure
particualrly for the relay mechanism you describe, and a final thought it
also sounds possible to implement using a Y-Value server that maps from alias
names to file/url names.

Cheers

Mark


Jim Starkey wrote:

> At 04:09 AM 4/26/01 +1000, Mark O'Donohue wrote:
> >
> > One thought I had was to in your design to build a common front end that
> > uses a general interface to connect to the server process (say for
> > discussion here DBEngineConnectionInterface) one implementation allows
> > (DBSocketEngineConnection) which
> > talks natively to a remote FB/IB database.
> > It then allows for another implementation (DBJNIEngineConnection) that
> > connect to the engine and databse on the same
> > machine without going through a socket layer.
>
> I would like to quibble with your nomenclature on architectural
> grounds. During the Borland years much of the overall architecture
> has been lost (or at least misplaced) with regard to what is
> engine, what is server, and what is plumbing. The original
> architecture, though muddled, is still in place in the code,
> though not in the build. Since it is clear to me that
> a) Firebird and Interbase are going to diverge, and
> b) interoperability is essential, the original architecture
> is as important as ever. Let's start by clearing up the
> nomenclature.
>

{big snip]