Dimitry Sibiryakov wrote:

> None. Just a crazy idea that all providers can export the same
>public API and be used by embedded applications directly, without Y-
>valve.
>

Why? That would require that every provider export the entire client
interface, which has grown to include all sorts of stuff. Worse, it
would break virtually every layered service in the client interface
because it would no longer know who to call. It would render the remote
interface non-transparent, break rolling upgrades. It would alway
require that either every provider independently load the configuration
or that a host program would have to do so. It would require that every
host program understand which API calls are available in which instance
of the provider API. It would require that every host program contain
the logic to locate and load a provider.

The provider architecture is designed to present a single, upwards
compatible, consistent, stable API, which is the Y-valve. The Y-valve,
in turn, has to deal with environment, history, and configurations.

If you want to suggest changes to the provider API, please do so
immediately, if not sooner. As soon as we are in a position to commit
the changes to support the Firebird 2.0 ODS we will need to freeze it do
support backwards compatibility to the current Vulcan ODS. At that
point, the core provider interface will be frozen for perpetuity. It
can always be extended (part of the core provider API gives an interface
version number), but it never be changed.