Roman Rokytskyy wrote:

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

The isc_create_database calls has a "subsystem type", an integer field,
that identifies a specific provider. Although it isn't implemented yet,
I plan to define the type codes in the <provider> object in the
configuration files. If I had it to do over, I would use a character
string, but it's too late now.

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

I'm not going to defend the services API, nor am I going to entertain
the idea that anything implemented in that morass should guide future
development.

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

Putting aside the services API for the moment, all attachments are end
to end connections between the client and engine. No tranmission layer
-- y-valve, remote interface, remote server, or gateway -- is addressable.

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

I disagree. We may decide to do option c). Or maybe d). The services
API is nothing more than a way to invoke one of a small set of hardcoded
utilities linked the the database. The utilities, incidentally, loop
back into the Y-valve to do their thing. I haven't been through the
code yet, but I wouldn't be surprised if various name transformations
break the services API.

In any case, the services API has *nothing* to do with database
capabilities. Could we get back on topic, please?

As I understand it, you and Jaybird have no interest in asking a
database what capabilities it has, and would prefer to release a new
Jaybird for every beta and point release so you can correlate version
string with capabilities. That's ok with me; I don't have any problems
with that. But I'm not at all sure other projects will think kit
building that much fun...

--

Jim Starkey
Netfrastructure, Inc.
978 526-1376