I would prefer there be no less than one and as few separate components as
possible to implement these new features. Having a visual component to wrap
something a method or two at the session level can accomplish is overkill.
However, I also realize that people will think I don't support them if I
don't have at least one IB_Services component on the palette.

Let's look at making a complete wrapper for them all called TIB_Services.

Regards,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: "Claudio Valderrama C." <cvalde@...>
To: "ibolist" <IBObjects@egroups.com>
Sent: Thursday, January 18, 2001 12:34 AM
Subject: [IBO] The Services API... again.


> Hello, a couple of days ago I asked if people have the need for a set of
> components in IBO that interface with IB/FB in the Services API functions.
> The result from this list was full apathy: only Helen replied.
> Warning: this is totally unofficial info. Now I have Jason facing some
> pressure to implement OO wrappers for the Services API. I'm not sure how
the
> issue turned upside-down in a few days, but it happened!
> I think that people come to IBO mainly because it's a good layer on top of
> IB's data services and not because it could be used to administer IB with
a
> complete tool set. However, if the wind is blowing in another direction
and
> Jason wants to continue the adventure, I think my only option is to
request
> comments from this list, in the hopes I will get this time more generous
> feedback. So, what would you expect from a possible IBO-Services layer? I
> have no intention to take a peek at how IBX works and also I'm still on
D3.
> Furthermore, I ignore the hierarchy (if any) used by IBX-Services
components
> and I don't think I should follow it, too.
> Thanks for reading.
>
> C.
> ---------
> Claudio Valderrama C.
> Ingeniero en Informática - Consultor independiente
> http://www.cvalde.com