Hi,

> 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
attachments/databases.
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
subsystem.

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

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