Subject Re: [Firebird-Architect] Vulcan services part II
Author Arno Brinkman

>>> 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
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.

Arno Brinkman

General database developer support:

Firebird open source database (based on IB-OE) with many SQL-99 features:

Support list for Interbase and Firebird users:

Nederlandse firebird nieuwsgroep: