| Subject | Re: [IBO] IBO for Delphi 2009 |
|---|---|
| Author | Helen Borrie |
| Post date | 2009-04-30T01:03:10Z |
At 01:54 AM 30/04/2009, m. Th. wrote:
M. Tonies wrote
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.
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. 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.
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.
2) without a real-life development environment to test in, Jason is more than ever before reliant on field-testers who *can* provide that.
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.
Just my 0.002 cents-worth.
Helen
M. Tonies wrote
>> - full Firebird 2.1/2.5 support, this requires quite some changes to IBODon'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.
>> with regard to parsing and aliassing
>>
>This is almost impossible to do in the next release. Just think aboutExternal 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.
>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).
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.
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. 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.
>...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. 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.
2) without a real-life development environment to test in, Jason is more than ever before reliant on field-testers who *can* provide that.
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.
Just my 0.002 cents-worth.
Helen