Hi,

At January 28, 2004, 11:34, Alexandre Benson Smith wrote:

> I started to read Developers group, after the anoucement of Vulcan and
> Initial Discussions about FB 2.0... I have some questions and doubts (I am
> really interested on cross connection cache of prepared statements), but I
> think I should read a bit more before ask something, the hearts, minds and
> souls there are so hot :) I don't even know what the Y-valve is :-))) and
> when I read a bunch of monograns like BLR, TLS, TDBB, etc.... I just strut
> on the chair, take a deep breath and continue reading As I understood what
> was told... :)

Here's a document that you would like as reference:
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_source_guide

Some definitions no longer exists in the code, but it will give you
some information as to what those acronyms refer to.

And, this is what a Y-valve is, written by Jim Starkey:

[Start quote...]
The Y-valve (why.c), named after a prosaic piece of marine plumbing, is
the layer that presents a single API to database clients, redirecting
control into one of a series of semantic equivalent subsystems. At
various times in history the subsystems included:

1. The core database engine
2. The previous version(s) of the database engine to handle obsolete
ODSes
3. The remote interface
4. The Rdb gateway
5. The Oracle gateway
6. The pipe interface

The Y-valve has been architected since the days of the Reedy Meadow
research center around a single fixed entrypoint table generated by
multiple conditional inclusions of an entrypoint definition file with
different definitions of an entrypoint macro. Arcane, possibly ugly,
but it got the job done (the mainstream Unix systems hadn't yet gotten
around from DEC, Apollo, and Microsoft that dynamic libraries were good
stuff). Those days are, happily, long gone.

Among the problems with the architecture is that each subsystem, by
design independent, must have its dirty little fingers in the Y-valve,
which makes it somewhat of a mess. It also requires that the entire
system be more or less statically linked.

A better architecture would be to make the Y-valve an independent
component that finds it subsystems dynamically, with provision, if
absolutely necessary, for static linking for embedded use in toasters.

Now that the code base has been shifted, the solution is pretty much
obvious. There should be a single C++ class that defines the cannonical
subsystem interface (with a method to return version number for
extensibility). Each subsystem would export and subclassed version of
the cannonical interface. The Y valve would be driven by configuration
mechanism (to be defined) listing the available (and appropriate)
subsystems. The configuration mechanism needs substantial flexibility
for allow for different configurations for different users or projects
and different configurations for the client and the server.

The original Interbase strategy for ODS changes was to support the old
version of the engine for a major release, letting the Y-valve find a
subsystem that know how to handle a database based on ODS version.
Borland feel into the trap of doing in-place ODS upgrades with
predictate consequences. The ODS is overdue for upgrading.
Re-designing the Y valve to easily support multiple engines now is the
right way to address the problem. Properly done, it would allow
peaceful co-existence of Superserver and embedded client on the same
system (but not the same database!).
[...End quote]

--
Best regards,
Daniel Rail
Senior System Engineer
ACCRA Group Inc. (www.accra.ca)
ACCRA Med Software Inc. (www.filopto.com)