At 08:55 PM 03-01-01 -0400, you wrote:

>I've seen one discussion about the Services API being accessed through IBX.
>Besides it being supported only on D5, what are the OTHER objections to not
>use IBX for the Services API and IBO for data access? Why is people asking
>Jason to provide high level access to the Services API? Or it's only because
>IBX requires D5? I'm curious to understand the issue. I'm not posting a
>troll and I don't want a flame war.

I don't see a problem with using the IBX service components if one wants to
go the Services API route and one feels comfortable that the API will
behave as expected.

Where I have reservations is not with IBX but with the Services API
itself. Here are the problems as I currently see them:

1) Ann Harrison says the Services API is a crock. She has said so all
along, i.e. back in the ISC days as well. I trust her judgment on this.

2) There is evidence that the API is also buggy, unless someone has sorted
out the problem of the backup call not backing up data, i.e. it does a
metadata-only update.

3) Borland hasn't released the source for the Services API. The only
documentation available is the unfinished beta API manual.

4) The Services API is not available for sub-IB 6 databases, nor for
Classic version. (Mark Duquette's comment earlier today on IBDI was that
it's available for Classic and simply needs to be implemented).

From an IBO point of view, I feel that IBO already covers a lot of the
ground that the Services API does, via the regular API. If you don't want
to build your own, there is IB_WISQL. By adding free tools like Martin
Schmid's IBBackup, or rolling your own wrapper for the command-line tools,
it's possible to build up a SYSDBA utility set that doesn't need to access
the Services API.

Helen

All for Open and Open for All
InterBase Developer Initiative · http://www.interbase2000.org
_______________________________________________________