Hi,

>>> 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.
>
> "We"? Who exactly is "we"? At least Roman and I think that some
> part of services provider _must_ be binded (I'd even say embedded) to
> an engine. Not whole, but quite definite part.

:) Ok, "we" was bad chosen word.

But services provider is currently not ODS dependend and configurable and directly using engine11 would ignore that
part.
Adding/Modifing a user does that belong to the engine? Not when we're talking a global user-repository. These are things
for the service, right?

I agree with you that engine could support tasks for backup/restore, but that would be an other backup/restore than gbak
currently does. Currently it's really not the time to implement this.

Regards,
Arno Brinkman
ABVisie

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
General database developer support:
http://www.databasedevelopmentforum.com

Firebird open source database (based on IB-OE) with many SQL-99 features:
http://www.firebirdsql.org
http://www.firebirdsql.info

Support list for Interbase and Firebird users:
firebird-support@yahoogroups.com

Nederlandse firebird nieuwsgroep:
news://newsgroups.firebirdsql.info