Thank you everyone for your feedback.

I think those who are still working with anything prior to Delphi/CPPB
version 4 are not looking for new components and functionality to work with.
They are likely just maintaining their applications. Thus, support for D3/C3
shall be dropped from future IBO 4.x versions. I will keep supporting the
other earlier versions as long as it is convenient to do so. I don't foresee
any problems for them.

As for the future:

I will maintain the IBO 4.x (ANSI) code as long as I can for all future
versions of Delphi/CPPB & IB/FB that don't cause major shakeups to do so. It
will remain the strictly ANSI based code with some limited support for
Unicode/UTF8/etc. Once EDO is ready, I will strongly discourage anyone from
continuing with IBO 4.x (ANSI). I am very remiss I was not better prepared
for making a Unicode version while D2009 was in the making.

I have been working on IBO 5.x, which is actually EDO 1.x (Enterprise Data
Objects) and am making good progress. I plan to only support Delphi/CPPB
2009 and higher with EDO so that I can fully take advantage of Unicode.
There will migration tools to help make the transition of your application
code to go from IBO 4.x to EDO 1.x. By having both IBO and EDO as entirely
separate component suites, it will be possible to use both in your
application at the same time. This should make the transition easier in some
cases.

In the big picture, my intent is to turn my development focus to a clean
foundation so that I can continue to innovate and take full advantage of new
capabilities. I welcome any comments or suggestions on things in IBO that
should be changed to take advantage of new features available in the EDO
product. I am still facing questions like doing away with all pointers and
using dynamic arrays instead. The intent here is to ready things for
platform independent code as well as ready it for JIT (just-in-time)
compiling, such as can be done in the .NET realm. Other things are how to
efficiently handle the driver layer while being universal. I am going to
build up the session component to handle the driver related things there and
keep the connection, transaction, dataset, etc. components driver
independent. This is similar to how the BDE did things.

The reason for the switch from IBO 5.x to EDO 1.x is I want to expand the
horizons of where my data access architecture can be utilized. I want to
both be prepared for greater divergence between InterBase and Firebird as
well as bring other back-end databases into the mix.

Initially, I will just have separate drivers for InterBase and Firebird. I
will more or less duplicate all of the IBO functionality in the more
universal driver based format. This will be EDO 1.x. Then, I intend on
supporting other databases with EDO 2.x. I plan to use dynamic run-time
packages to encapsulate all of this. Anyone here is welcome to suggest what
databases they would like to see focus placed on for the development of
drivers.

I have also been working with FPC/Lazarus to expore its potential. I am
quite impressed with what is available there. For those who would like to
take their applications cross-platform, this is likely very good news. There
was an FPC port of IBO (non-visual) that someone did with my authorization
that I had a copy of at one time but I cannot find it right now. If someone
out there has a copy of it I would be very grateful to have it sent to me. I
plan to port at least the non-visual things to FPC. I'm not sure if this
will be under the EDO name or some other name. It depends on if I will need
a separate code base or not.

Also, does anyone have a good JAVA-script compiler or know of one that I can
use in a project I am working on? I have picked up the code of the Thtml
components (donated to anyone in public domain) and been working with them
so that I can have my own native code web browser component. It was a very
good start and it hasn't been too difficult to build in the more advanced
CSS capabilities I needed. What I'm lacking at this point is the ability to
perform JAVA-script events. This capability would make this a very viable
compoent to add to my EDO offering. I'd like to make a nice web-based
administration tool like IB_SQL but able to be ran locally or over the web.

Also, I would like to encourage everyone to remember that as of about two
and a half years ago I left my full-time day job with health benefits and a
very good salary so that I could devote more time to IBO's development. My
wife and children have been patient and gracious with me as we had to go
through a difficult process of figuring out how to live while making a lot
less money. This put us on a path of finding out how to live without my
salary that was almost $100,000 USD a year. We had been saving up in order
to make this transition and thought we were ready. Not long after quitting
my job, we thought things were going good but about two years ago I got hit
with a frivolous lawsuit and lost all the savings I had and the home we had
settled into with all of our equity. Thus, I have gone through hell trying
to recover from these hard times and figure out how to put our lives back
together. This is why IBO has been neglected for some time while I dealt
with this challenge, among other challenges.

I am very pleased to report that as of this month we are now settled in a
suitable home for us that we own free and clear without a mortgage. We
bought a cheap foreclosure property out in the country. We used what was
left of my state retirement account, so my sole retirement is now IBO/EDO.
The home needs a lot of repairs and it is nothing like the nice homes we
used to live in. But, it is better than the moldy rundown trailer my family
of 10 was living in for the past two years. We can settle in here. It feels
so wonderful to have a room suitable for an office again. My family knows my
heart is with IBO and has been willing to give up city life and a much nicer
lifestyle so that I can stay with it. My day job wanted to shift to using
all Microsoft development tools so I had to make the choice. IBO on a very
limited part-time basis and keep a dependable salary or stay with IBO and
let the day job go. I want to make all of this sacrifice to support my
decision worth their while somehow. They really believe in me and my ability
to go out totally on my own and make our livelihood. I hope to prove them
right. With your help, I shall.

I am grateful the amount of IBO sales is currently at a level that we can
comfortably survive on, but we would like to do more than just survive. I
hope anyone who is financially able will make sure to keep their source
access subscription up to date (on an annual basis) and possibly consider
catching up past amounts if you have the financial means to do so. (I
certainly won't require it of anyone.) I am working on being more
communicative to send out reminder emails about subscription renewals, so
please look forward to them. Also, I am very willing to work with others who
are facing hard times. Any who wish to use my tools but do not have the
means to afford them can apply for a Trustware license. This includes
purposes such as hobbyist projects, educational use, non-profit or charity
groups, business start-ups, etc. I now know for myself what hard times are
like so my level of compassion is increased.

Thanks,
Jason Wharton