|Subject||Re: Vulcan services part II|
> But services provider is currently not ODS dependend andThe services provider depends on many things that should be supported
> configurable and directly using engine11 would ignore that
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 whenI think - no. The global user repositories require external management
> we're talking a global user-repository. These are things
> for the service, right?
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
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,Why not? Each gbak happens to write its own backup format. nback
> but that would be an other backup/restore than gbak currently does.
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