> IMHO, don't go nuts with adding components, but add as many
> as seems necessary. Don't compromise ease of use or functionality
> for the sake of reducing component count by one or two. IBO has
> a LOT of components, but it also has a LOT of power.

I would add my support to this statement. I would suggest that the
"two complex" complaint that sometimes gets thrown at IBO has more to
do with the number of properties on a given component than it has to
do with the number of components.

As for the services API itself, I do think that Jason's original idea
of a simple TIB_Services component is probably sufficient. There is
enough overlap in the property requirements for this to be the most
efficient form of implementation. (This is at least my initial
opinion, I have not yet studied the requirements in deail.)

I do have one interesting suggestion to go along with this - related
to an earlier posting "Interbase Connection = Reinventing the wheel".
It may be interesting to setup a component to manage a set of
connection definitions (a simple history facility if you like). Such
a facility, integrated with the logon prompt and the TIB_Services
component may make writing utility applications a bit simpler.

Just a thought. (As Homer Simpson said: "leave me alone with my
thought" - emphasis on the singular ;-)

Geoff Worboys
Telesis Computing