Another feature of Firebird that did not survive the transfer to Vulcan
is the Services API. There is a general agreement that it will be
implemented as a separate provider under the dispatch module and that
the remote plumbing (server and remote provider) will transmit its calls.

In building the Services API, the Borland engineers largely destroyed
the modularity of the InterBase engine and the layered utilities,
allowing utility programs to call code in the engine that was not
designed to have architecturally controlled interfaces. That
methodology will not work with Vulcan. Moreover, separating and
simplifying the utilities will make the whole system more maintainable.

My suggestion is that we separate each of the utilities into a backend
shared library and a front-end program that calls the library. The
shared library uses the services API as its interface. The program is a
very thin layer that provides a user interface for the library. In the
process, all the utilities should convert to using the OSRI error
handling classes in Vulcan, and must eliminate calls into internal
engine code.

Regards,


Ann