Jason Wharton wrote:

>> GW> The problem for other developers is that this change may
>> GW> complicate their upgrade process a bit.
>>
>> Yep, a bit more work for upgrading, in exchange of more
>> speed... looks like a fair trade to me.

> I think any major changes such as this that will force painful
> migration of legacy apps should go into IBO 5.x.

> The IBO 4.x branch will be maintained for bug fixes and
> backwards compatibility with previous versions of Delphi.

These are important points that highlight the need to make
clear what I have been doing...


I have been working on a version of IBO that fits my needs.
No-one is paying me to do this so I work on those bits that
are of direct use to me and that I can work with directly.

For example I currently try to maintain D6 support simply
because I have that version installed and can test it - and
also because it marks a point where significant amounts of
legacy IBO code can be removed rather than checked/converted.

Another example is that I need the new optimisations so they
are in the code I am developing. In the work I am doing now I
have removed the old, string intensive, code so that I did not
have to check or convert it.

Note too that I am doing the work because I don't expect a
useful IBO v5 for at least 12 months and if I was able to wait
that long I would not be using Delphi at all but continuing
with my C++ work. I am spending time upgrading IBO because I
believe that will be the fastest way to get where I need to go
with my applications.

My work is concentrating on Firebird issues. I don't have any
recent versions of Interbase and have not tracked the details
of the changes they made - just not interested. So I cannot
test whether the changes I am making are compatible with IB.


The very reasonable restrictions that Jason wants to place on
the 4.x branch of the code (backwards compatibility etc),
essentially mean that what I am producing is a separate branch.
I have called it v4.10 but perhaps v4U.10 or something to mark
it as separate to the main IBO v4 development.

The v4U branch is for those like me (or perhaps just me) who
want Unicode support without waiting for IBO v5... and since
Unicode support is only relevant to D2009+ all attempts to
maintain support for older Delphi's is probably a waste of
effort. (My own opinion is that anyone that does not want
unicode should stay with their pre-D2009 versions of Delphi
and use IBO v4.8.7.)

A similar, but less substantial, logic says anyone converting
up to unicode is going to have to spent some time and effort
at least checking their code... and this is the justification
I would give for accepting the new column attributes
optimisation, another being the performance boost (and another
being that I have deleted the old code and don't want to put
it back in again).

Of course the big problem with this argument is that we will
eventually end up with two legacy branches, 4.x and 4U.x and
who really wants to maintain two branches when one would do?

(A survey of IBO developers could help to establish realistic
boundaries of Delphi and Firebird or Interbase version support
required in IBObjects.)

> Those wanting the improved architecture will need to migrate
> to the 5.x product line.

I am happy for v5 to be something very new and restructured but
do consider it a mistake not to have a unicode capable version
of IBO v4.

It may have been different planning v5 when unicode support in
Delphi and Firebird were still in their infancy... but these
products have unicode well established now and IBO needs a
compatible solution (and v4.9 is definitely not it).

--
Geoff Worboys
Telesis Computing