> In this case I have some problems in understanding the layring of
> this thing... Services module(s) in my understanding must not be on
> the same level with engine providers. I will come back after reading
> the docs and the code.

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.

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.

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.

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.

I have to admit that what I wrote before has nothing to do with the
Services API, which I wrongly thought to be located one layer above
the engine or remote providers and thus being able to execute some
requests against them.

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.

Roman