> > I mean utilities embedded in engine as threaded services. Why
> > they call Y-valve instead of internal engine classes? Just because
> > Jim decided to extract them to a separate provider?
>
> Because else you bind services provider directly to an engine, this
> is not what we want.

Can you provide good reasons why adding functionality to dump/recreate
from dump (that's what gbak is), validate database, gather statistics
and so on is a "bad thing"(tm)?

Me and Dmitry Sibiryakov have provided good reasons for that:

- most of the code is in the engine anyway; none of the utilities
(except gstat which goes to the file directly and has to handle all
ODSes at once) will work with another provider that knows nothing
about the things like isc_dpb_gbak_attach (like gateway to another DB);

- restores layering and simplifies the request flow through the
layers; no need to provide hacks that will prevent endless loops in
callbacks;

- provides necessary abstraction of the operations hidden by the
interfaces; consider simply how gbak is going to work when you remove
the BLR support and isc_compile_request entry points?

- gives you a possibility to extend SQL to do those tasks;

What are your reasons for oposing this idea?

Roman