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.

The general path from an application program to the engine
is this:

Application
----------------
Y-Valve
----------------
Remote interface
----------------
(line protocol)
----------------
Remote server
----------------
Y-Valve
----------------
Engine

The Remote interface, Y-valves, and Engine have isomorphic
interfaces.

Database attachment works line this:

1. The application calls isc_attach_database, which is
fielded by the local Y-valve.

2. The Y-valve polls its subsystems (a remote interface
per network type plus an option "classic" engine) to
see if any can make the attachment.

3. A remote interface module (typically TCP) recognizes
a reference to a remote server (which may be on the
same system). The remote interface strips off the
node name from the database attach string and send it
as and the database parameter block across the wire
to the remote server.

4. The remote interface creates a network connection to
a remote server (mechanism is irrelevant). The collects
its arguments -- connect string and dpm -- an issues
a isc_attach_database against its local Y-valve.

5. The (remote) Y-valve polls its subsystems (an engine,
possible an version n-1 engine, possibly an engine
from the other camp, and remote interfaces) to see if
any can make the attachment.

6. The (remote) engine recogizes a file name (or soon a
database name) that it understands. The engine creates
an attachment (whatever that means to the engine) and
returns a "handle" for the attachment to its caller,
the (remote) Y-valve.

7. The (remote) Y-valve encapsulates the handle from the
subsystem with an indication of which subsystem ponied
up, and returns a handle to the encapsulation to its
caller, the remote server.

8. The remote server takes note of the handle returned by
the Y-valve for future reference, and returns "success"
and a handle to the remote interface at the other end
of the network connection.

9. The remote interface picks up the handle from the remote
server off the wire, encapsulates it, and returns a
handle to its caller, the (local) Y-valve.

10. The (local) Y-valve encapsulates the handle from the
subsystem with an indication of which subsystem ponied
up, and returns a handle to the encapsulation to its
caller, the application.

The important parts of the architecture are:

1. The engine doesn't know anything about the network.
2. The server doesn't know anything about engines.
3. The Y-valves don't know anything about either networks
or engines, only an open-ended set of polymorphic subsystems.

The plumbing components (Y-valve, remote interface, remote server)
tranparently route calls and return results. Engines actually
execute the calls.

Please note that the architecture is open. New engines, networks,
and protocols can be phased in, coexisting peacefully with existing
components.

"DBEngineConnectionInterface" implies that it making a connection
to an engine. It isn't. It is making a connection to a remote
server which calls a Y-valve which (maybe) calls an engine. Or
maybe goes remote on a different network. Or maybe calls a gateway
to Oracle.

An essential step for Firebird to pry loose the server module,
the Y-valve, and the engine(s) into separate images to restore
the open architecture to allow Firebird 2 to coexist with Firebird
1 and Interbase 6 (if they ever get it working). Then the
real fun of alternative protocols, gateways, and experimental
engine can begin.

Jim Starkey