Jim,

JS> What we're talking about is the API between the services provider and
JS> the callable version of the utility. As an internal API, it won't be
JS> visible to Delphi or any program that uses the published client API.
JS> The clients of the internal utility API will be a) the command line
JS> executable for the utility, e.g. gbak, b) the services provider, c) any
JS> GUI utility front end that enterprising developers might write.

<aside>
Sorry for not making myself clear. I might be just that kind of
enterprising developer. :-) So an object wrapper around those DLLs, be
it provided by Firebird or self-made, is needed. If it has to be
Delphi, then I guess it'll have to be self-made, but again I am at the
window waiting to see a POD, function-based but object-oriented new
API which can be used by languages other than C++ without playing
tricks with exceptions and the like. Then I'll have a more complete
idea of what I can do.
</aside>

Anyway, I'm not clear whether you plan to run that code server side or
client side. I think you are saying that the services API is going to
be layered on top (be a client) of this new thing, right? If so, and
if the services API is feature-complete, then I can't see why a) and
c) couldn't use it and why do they need to use an internal API
instead. Perhaps I'm just not enough into the internals...

Ciao
--
Nando Dessena
http://www.flamerobin.org