Subject Re: Vulcan services engine info. was (engine information (nr. of attachments, databases, db-name-info) for vulcan)
Author Arno Brinkman

> Ok, I have checked the original document for the architecture and it
> is written there that Services API should be supported by the
> "services" provider. Maybe this somehow fits the gbak/gfix features,
> but the requirements that you describe do not fit there anyway.

The services module indeed supports gsec/gfix/gbak already. Missing thing is currently returning the db-paths, number of
Also i doubt that isc_info_svc_server_version will currently return the correct information, but that's next.

While each engine override the subsystem calls, introducing a method in the subsystem that can return the needed engine
information sounds good to me.
The services module can call the in the Y-valve (Dispatcher) to ask for engine information and the dispatcher will walk
through all known providers and his subsystems to ask for information. This way the services module is able to handle
return the needed information.

> Also traversing all providers cannot be done by another provider, but
> a component above those. So, I still believe that additional API is
> needed to handle the "server-wide" requests.

The dispatcher can do this.

> And this is an extra API, different to the provider API and the
> Vulcan's configuration, since the one is rotating around the database
> name.

Depending on what the method has/does.

> As to my post about XML-RPC... Some time ago, if I remember correctly,
> Jim wanted to make all services available via the separate process
> that would call either gbak or gfix (or any other command) and
> translate their responses back in XML.

IMO you'll remain with the problem how to get the information and that's why proposal to add fb_engine_info() to the

> Frankly speaking, I do not see the possibility to handle your
> requirement without giving Vulcan's Y-valve a possibility to handle
> some specific requests by itself. Which, I am pretty sure, will be
> considered as breaking the layering and will be declared a "very bad
> thing" per se.

The Y-valve methods inherited also from the sub-system and those handles (dbHandle, svcHandle, reqHandle, blobHandle,
..) are internally mapped to the calling provider handles. For the engine-info call we don't have a (engine-) handle and
i doubt if we need it.

Arno Brinkman

General database developer support:

Firebird open source database (based on IB-OE) with many SQL-99 features:

Support list for Interbase and Firebird users:

Nederlandse firebird nieuwsgroep: