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

How does the create database fit your architecture - you cannot
connect to something that does not exist. In fact you have a shortcut
in your architecture, some kind of a flag - "if database is not there,
create it".

If you do not agree with this - please explain how does it differ from
another "database-less" operation, like gfix.

In fact, the Services API cannot be called database-less, there's no
call (except user management, where I agree with your ideas) that can
work without specifying the database path. It is quite database-aware,
but you cannot work through that attachment.

So, in fact the answer to the yet unknown question is one of the
following:

a) there is a single attachment to the database and all service
operations are accessible via SQL;

b) there is an attachment to the database where DDL and DML commands
can be issued and there is an attachment to the database where all
maintanence commands can be issued.

Borland, I think, went the a) path - they already have monitoring
tables instead of separate calls for the same purposes. The next thing
to come is something like CREATE BACKUP .... and so on.

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

I meant "outside the database attachment in current meaning" - an
attachment where you can issue the DDL and DML commands.

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

I don't. There is a Y-valve to which I attach. If I understand it
correctly, in Vulcan architecture application does not attach to the
provider (="engine" in your terms) - it always goes through some
client library. So, what I expect from that library, is to forward my
maintanence request to the suitable provider. I see no problem here.

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

Not me, the Y-valve will know. I do not want to know that there are
multiple providers behind my API. I do not care - I have my ISC API
and I tell it to do the job. And it either succeeds or fails.

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

100% correct.

So, the main question is whether we want to choose a) or we want to
choose b). When we choose a) it means that provider has to know all
possible service SQL statements. You want to add new one, you have to
modify the SQL interpreter. If we choose b) and use similar API that
it is now, we have a possibility to have "services-plugins" without
changing the provider.

Did I miss anything?

Roman