From Jim Starkey on the Firebird Development List 13th December 2003
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:
- The core database engine
- The previous version(s) of the database engine to handle obsolete ODSes
- The remote interface
- The Rdb gateway
- The Oracle gateway
- 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 independence, 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 a version number for extensibility). Each subsystem would export and subclassed version of the cannonical interface. The Y valve would be driven by a configuration mechanism (to be defined) listing the available (and appropriate) subsystems. The configuration mechanism needs substantial flexibility to 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 knew how to handle a database based on ODS version. Borland fell into the trap of doing in-place ODS upgrades with predictable 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!).