-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

A long time ago (somewhere in 1999), I asked why the backup/restore functionnality of gbak was not surfaced through the documented C-API. I identified functions, declared in ibase.h, but not documented which let me think it shouldn't be that big job to document some more and let people use it.

I was then told a *whole new* API, Service API, was designed in the IB 6 beta to allow such things as the backup through user programming. Indeed, the IB 6 API has got such and it works.

But we lost a very nice functionnality at the same time. Now the backup is completely local to the server and the target must be a local file on the server. gbak, which presumably use multiple of those API which nobody wanted to document at the time is more interesting : it can backup over the wire from a server to the client. I think it more closely stick to Jim's design of Y-gate, even allowing using a server to connect to another one and backup from there.

Not that I do not like the new Service API, though I miss that functionnality. And forking to exec gbak is not my cup of tea. I miss the ability to do the same as gbak, from my own programming.

Yes, the definitive documentation, the source, is there. But before I jump in and reverse engineer gbak interface to the server I would like to ask this question to the community :

(*) What's our community goal/wish regarding things which were possible *before* Services existed and that are now duplicated well or not by the Services API ? Is there a will to deprecate one and push further the other ? Do we want to maintain for ages both things ? Shouldn't we even drop the Services API (while it is still "young" and few used), and document appropriately the old way of doing things ?

I really wonder why was it so necessary to invent that Services API, while all the required functionnality existed ? (gbak, gfix, and so on... : didn't all those utilities did their work through the shared client library API ?)

Olivier Mascia, om@..., Senior Software Engineer
T.I.P. Group S.A., www.tipgroup.com, Director


-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.8

iQA/AwUBOmCvS6SbOXgumurfEQJA0wCfbb3PfujNjvydpVlSknCwwgGKRlwAoNJs
2QhIUah4gGxjSGZ+bpdyMBFy
=7TeE
-----END PGP SIGNATURE-----