Claudio,

> 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.

the IBX wrapping of the service API is decent; the services API itself
is not.
Honestly, I would like to see it dropped and rearchitectured from
scratch.
I have always seen IBO as a data access layer, I would like it to remain
concentrated on this area; I don't think IBO would come out with
anything far better than IBX in the services area, given the underlying
API implementation, so why bothering?
At least, if IBO has to go through the services path, make it an
optional additional package.

> Furthermore, I ignore the hierarchy (if any) used by IBX-Services components
> and I don't think I should follow it, too.

I believe that when you implement software of any kind you simply *must*
be aware of how your competitor products work; you don't have to mimic
them, just get to know them (possibly avoiding their errors).
Ciao
--
____
_/\/ando