Helen Borrie wrote:

> At 01:54 AM 30/04/2009, m. Th. wrote:
>
> M. Tonies wrote
>
>
>>> - full Firebird 2.1/2.5 support, this requires quite some changes to IBO
>>> with regard to parsing and aliassing
>>>
>>>
>
> Don't confuse 2.1 and 2.5. V.2.5 (now in its first beta) will change a whole bunch of things. It should be thought of as the precursor to Firebird 3. What it's *not* is a rollup of Fb 2.0 and 2.1. There will be at least one more beta before the 2.5 release candidates start.
>

Agreed. As an aside, why it's named 2.5? 3.0 sounds more appropriate for me.

>
>> This is almost impossible to do in the next release. Just think about
>> CTE, EXECUTE STATEMENT, EXECUTE BLOCK... especially if we think that in 2.5 we can query other databases from within the current database (in
>> which we are logged in).
>>
>
> External database access in 2.5 is not made via a DSQL connection. The external connection is performed *by the engine, on the server*, from within PSQL, via EXECUTE STATEMENT, in a separate, autonomous transaction that the client side has no control over. Its usage is thus restricted it to SPs, Triggers (God forbid!) and EXECUTE BLOCK blocks. As now, the API has to take care of structures across the wire. Permissions will definitely matter; but these are database design issues that don't impact the API.
>

I'm thinking at parsing, Helen, at parsing. Functions like
Get/SetSQLWhere(..), the Filter property of TDataSet descendants
(TIBOQuery, TIBOTable) - all these (will) still work with CTE, Derived
Tables, EXECUTE STATEMENT/BLOCK? Or perhaps it's better/required at
least in some cases to avoid parsing? (Ie. implement
IsParsable(aSQLText: string): boolean; or something similar)

> My expectation is that Jason's main issue will be the need to beef up the application layer's recognition of database namespace when operating on these multi-database virtual sets in RequestLive conditions. It doesn't seem all that simple, to me, but I'm guessing that, with the work he did with DB2 in his old job in Arizona, Jason would at least have some concept of a) what's wanted for 2.5 and b) what's ahead for 3.0. But there's *no way* that 2.0/2.1 support has to cover this.
>
>

+1.

> IBO 4.8.7 has been stable for Fb 2/2.1 support with the older Delphi model for some long time now. The current demand for D2009 compatibility seems "urgent" for the relatively small number of shops that have taken it up.

"Relatively small"? With what do you compare? Almost any vendor in the
Delphi market supports D2009.
"Urgent"? What do you mean? D2009 was released in August 2008. 8 (eight)
months ago. Tiburon's Field Test (the code name for D2009) started
(AFAIK) in Feb. 2008. D2010 is in the works. As well as Fb 2.5 _and_ Fb
3.0 (as you know).
You see, the main problem isn't 'urgent' (which sometimes implies a
deadline) but the fact that 'we' (IBO community) cannot keep the pace.
And it's too bad because this can be easily fixed, if Jason minimizes
his response time.

> The issue of UTF8 client support is still wide open for Delphi, considering that D2009 on its own can't provide clean or adequate support for it and older Delphis need TNT to achieve it. The "unusable Alpha Version" thread seems (erroneously) to suggest that IBO has a duty to fix what Embarcadero has broken.
>
>

I cannot follow you here. Can you explain more clearer?

FTR, Delphi 2009's string is UTF16 which supersedes UTF8 (in our
discussion). Also, it has an UTF8String string type as well as other
string types.
In the "Unusable Alpha Version" Andreas (AFAIU) encountered some
show-stoppers which he fixed and tried to contact Jason to send the
fixes. I behaved in the same manner.

In order to implement Unicode, the internal structure of a string must
be changed. This is/was a reality for _any_ software company who
make/made the transition from ASCII/ANSI to Unicode (we saw Microsoft
and now EMBT). Is the difference from [one character]/[byte] to [one
character]/[two bytes]. If IBO didn't presume that a byte is a
character, the library would work immediately. It would need only a
(re)build. But because IBO (as well as many many other projects) fiddled
with the internal structure of a string (it was a very common practice
in the old days) that's why we must change these parts.

>> ...and especially when we think that he's trying to do it *alone*...
>>
>
> *Alone* is not a new situation w.r.t. Jason's IBO development.

Yes, unfortunately. Jason is our point of failure.

> Two things that seem (to me, at least) to be of intense importance now are:
>
> 1) such substantial R & D costs time and money. For a breadwinner with seven children, it's not hard for anyone to figure out that a supply of income must be an essential element in the equation.
>
>

Yes, sure. I didn't think _at_all_ in other way. In fact, we're old
trustware users and we try, by helping Jason now when he needs, to 'pay'
him as much as we can.

> 2) without a real-life development environment to test in, Jason is more than ever before reliant on field-testers who *can* provide that.
>
>

Of course, but we need (badly) his releases. If you're attentive at our
posts as well as at the issues in SourceForge's trackers, we are
_in_front_ of him. If he doesn't release a new version with fixes for
our show-stoppers how can we test? By fixing small issues in order to
advance is acceptable (imho), but shall we try to fork his source code?
Ok, today (almost) anyone can do this but if we invest resources in
forking IBO, then why wait Jason?

> If a situation arose where both 1) and 2) came rolled up together, i.e., if Jason were in one of more contract development positions with those sites that most need the bleeding edge features, it's likely to be infinitely more favourable to success and satisfaction all around.
>

Sure. We help him as much as we can, as I said (we are a small
non-profit organization). And, mind you, the problem isn't so much to
provide or not to provide D2009 support. Due the somewhat-breaking
nature of D2009 and his community acceptance (see EMBT newsgroups,
different blogs, Delphi-related questions at StackOverflow.com aso.) as
well as EMBT's future plans (Firebird support, 64-bit, cross-platform
compiler etc.) having D2009 support in timely manner is something which
is necessary not so much for us (in order to 'Unicodize' our apps) but
for Jason in his fight with players _much_ bigger than him (DevRace, RO,
DevArt/CoreLab, Zeos (etc.) and soon EMBT, not to mention Upscene (hello
Martjin!) and HK-Soft which also provide connectivity solutions for Fb),
*if* he wants to survive as an Delphi software vendor.

> Just my 0.002 cents-worth.
>
> Helen
>

My 0.02c also. Nice discussion btw. :-)

m. Th.