I see IBO playing a role in these multi-tier servers as the means to
communicate with the database but for me to embark on creating a whole new
thin client/packet transporting system would simply to be starting a new
product in an environment there are already lots of competitors in. ASTA is
one such product that comes to mind.

Also, you can count on me staying in the Delphi realm. I have no desire or
ambition to branch over into the JAVA, C++, or any other compiler
environment. I have pledged my support to anyone who wants to get involved
in a joint effort to port IBO's architecture into other arenas but I am not
going to do it by myself.

Thanks for the suggestions.

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

----- Original Message -----
From: "Marius Popa" <mpopa@...>
To: <IBObjects@yahoogroups.com>
Sent: Tuesday, February 20, 2001 7:14 PM
Subject: [IBO] future ...IBO-Java,IBOc++,or MSobjects ???


> i thought what will be the next move of ibo ...
> in the future i will use diferent tools for my projects (C++,java)
> and i need real objects to work with
> -look to develop from some classes that connect to ib
> without any gds.dll
> - don't like the jdbc aproach (to fuzzy for me ...)
> for example if i need to develop for some palm or pocketpc to have the
objects
> at my hand if i have to use VC++ or the net platform to have them also
with me
> shure i can use ib-perl but don't know yet enough perl to use it with
> visual perl
> ok the next move of the ibo should be the connection sharing arena
> if you have to have 3000 users on your server what you do ??
> have to keep the people on the same conn. but without them to observe
> i know there is some dbovernet but they do'nt have the trustware ideea :(
> the other question is if the ibo-wave will move to the other db's
> like ms,or oracle ...
> love the ideea of oodb but look at ibo they are oo and db
> shure is hard to port it but the ideea is to work directly with the api in
> a oo way
> like u do
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>