Hi,

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

I don't understand your example.

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

Depending on what you want ofcourse, but currently we've no external user-verification possibility so this should be
handled somewhere and the engine doesn't look seem the right place to me.

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

User management is already there by gsec, so i don't understand the problem.

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

Server is still there but catches traffic only and redirects it to the y-valve.

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

I understand your point, but for some reason i don't feel comfortable with it.

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

Well vulcan needs to go alpha ASAP and we want a solution that doesn't take to much time/effort, but still fits in the
architecture and will be useable in future too.

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