> But services provider is currently not ODS dependend and
> configurable and directly using engine11 would ignore that
> part.

The services provider depends on many things that should be supported
in the engine in order to function correctly. If gbak once decides to
compile request that can be compiled by engine12, but not engine11 and
engine8, it won't be able to work with those providers. How will you
solve that problem then?

> 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 think - no. The global user repositories require external management
and we should not provide any capability to do this, even for the
regular security databases.

It just happened that one of our global user repositories is a
Firebird database, but services API should not be used to manage it
like the Services API should not be used to add users to LDAP or
ActiveDirectory. It also can happen that people will implement their
own security database and a PAM module to handle the authentication.
Will you provide a possibility to extend SAPI with own user management
modules?

The whole concept of the SAPI was that you connect to a server and
execute a server-wide task. Now our architecture had changed and we
don't really have a server anymore.

> I agree with you that engine could support tasks for backup/restore,
> but that would be an other backup/restore than gbak currently does.

Why not? Each gbak happens to write its own backup format. nback
writes its own difference file format, all is version dependend and in
general case you cannot interchange them.

> Currently it's really not the time to implement this.

That is another question. "We have no time" and "we won't do this" are
different things.

Roman