On 25/07/2005 19:02 GMT+1, Roman Rokytskyy wrote:

>Personally I have a problem when Services API is considered to be
>server-related. It successfully works in embedded mode and I see no
>reason to break it.
>
>

There is of course no urgent reason to break what we already have, how
good or bad it is.

>Currently Services API provides:
>
>- user management
>- database backup/restore
>- database maintanence (gfix & Co.)
>
>All these features make sense in all modes. So, the main difference
>between call via Services API and isc_database_info is that you can
>call it without attaching to the database first.
>

Database backup / restore would be just fine attaching to the DB first
(restore is just a special case of create_database). That's fine and
politically similar to many other systems today to get a
services_attachment to issue such commands, but it could as well be done
on the database attachment concept.

The same goes for gfix & Co. of course.

>I think that our main problem communicating with Jim is that we still
>use term "server" referring to any attachment that does not need a
>database and for Jim this is "a part of the process that accepts
>socket connections and translates them into internal engine calls".
>For Jim there cannot be "embedded server" since this is contradiction
>in terms, for me personally this means only a library that exports
>current ISC API and provides all capabilities that remote instance
>has, however runs in the same process. So, most likely we have to
>start using another word - "s/server/engine/g".
>
>

There is no server in the architecture. There are servers in some
implementations of the architecture.

If you didn't swapped server and engine meaning and meant attaching to
the engine outside of the context of a database attacment, then the
problem is still open. It's just a bit wider now. :)

In the current architecture you can't know (or you shouldn't know or
have to know) *which* engine will serve your database attachment until
you will ask for attachment of that database. For this database, it
could be a 32 bits engine of version 2.x. For this database, it could be
a 64 bits engine. For this other one it could be a version x.y engine.
To what 'engine' do you want to attach in order to make administrative
work against this or that database, since you can't know at first what
engine will serve your requests for that database ?

To talk about gfix things, who knows how to change the setting 'XYZ' of
your database 'ABC' ? Answer: the engine that will in the end handle
your request for changing 'XYZ' setting on database 'ABC'. What engine
is this ? Answer: you'll know when you'll attach that database.

In other words, depending on the database 'ABC', the engine which will
handle your request might be very different than the one handling
database 'DEF'. To be able to 'connect' to the 'server' / 'service' /
'engine' before giving it instructions to change 'XYZ' on database 'ABC'
you would need to give the whole plumbing a hint on what database you
want to act upon, so that the right engine can be selected and handle
your request : it means you would have to give it the name of the
database you want to act upon. In other words, you would first need to
attach to that database.

I don't know if I carry the idea clearly or not, but the services api
whatever name or restructure you give it, is a huge shortcut accross the
architecture, making it a server-centric single-version thing which it
should never have become and which it obviously doesn't need to be.
That's the number one reason why I never started the work of adding
NBackup support in the Services API as Nicholay twice asked me to
consider doing (last year) : I never could convince myself it was wise
to do so there while adding more support to the un-supportable. ;-)

Some readers will object that I skipped over the 'user management' thing.
I'm one of those strongly convinced that user management does not belong
at the 'server' level.
It belongs to the database. To not be overwhelmed by having to define
user 'Olivier' and my password in a hundred different databases (should
I want to have the same password in all those databases), I would then
use one of the various security providers plugable to the databases and
would for instance chose to work with one which can authenticate me
through some external mechanism (kerberos based, NTLM based, whatever
based even a simple file based central repository). But I would never
have to define users in a global way at the 'server' or whatever level.
Unless the actual authentication method chosen decides otherwise, there
would be no link at first sight between user 'Olivier' of database 'A'
and user 'Olivier' of database 'B'. What authentication mechanism would
be used, which at the same time dictates wich users are allowed to
attach and within which limits, would all be based on choices written in
the database itself. Exit isc4.gdb/security.fdb, though security.fdb
could be kept and be the repository of the default security provider,
which would be attached by default to any database unless you specify
something else. The key point would be : you administrate security/users
at the database attachment level.

--
Olivier Mascia