Subject | Re: [Firebird-general] Firebird and Kylix |
---|---|
Author | Helen Borrie |
Post date | 2003-06-13T00:50Z |
Tom,
At 10:28 AM 13/06/2003 +1200, you wrote:
did the conversion of IBO to Kylix for Jason, but I'm in no way
instrumental in determining the course of IBO's evolution. Jason has
consistently required that the IBO-K data access follow the IBO for Delphi
model closely, and this has not been at all difficult to achieve.
With the native IBO data-aware controls, it's a different story. There are
problems with data-aware controls having the level of sophistication
implemented in the native IBO controls, which are going to need low-level
access that's currently not implemented in Kylix, or not covered by Borl's
licensing agreement regarding QT, or both. This seems to indicate a
significant investment in developer time and external QT licensing that the
potential market and the apparent flakiness of Kylix's future might rule out.
My thinking for now is that the IBO-K beta data access is fine for server
layers like yours, where the need for data-aware controls is minimal and/or
considered an undesirable cost in terms of resource usage. For server apps
- even with a thin GUI console - the architecture of native IBO data access
(as contrasted with the TDataset-compatible) lends itself strongly to
actual requirements, i.e. a non-interactive interface, or one that would be
realised most efficiently with the thinnest of non-data-aware controls for
display and input. It's the way we write thin console GUIs on Windows already.
There just doesn't seem (at present) to be the demand for Linux GUI clients
- apart from the requirement for Borl Dev Support personnel to create
gee-whiz, unreal-world demo apps on their laptops for Borcon events, and
the prevailing demand for a sophisticated, interactive GUI client for
newbie Linux Firebird admins who have cut their Firebird/Interbase teeth on
Windows with miracles like DBW and IBExpert.
The former is a "swipe" :-) but the latter could go in one of two
directions: the Windows emigres learn to love the directness and speed of
the command shell and the benefits of not having an X server competing with
the database server; or the Linux stalwarts en masse throw away their
insane prejudices ;-) about resource-consumption and get a predilection for
GUIs. (After all, I found KDE and wine ran *much* faster when I upgraded
my IBM 686 box with 128 MB RAM to a Duron 850 and 512 Mb, LOL.).
Getting back to "serious"...why wine? Well...umm...the Kylix IDE is a
Windows application.
A crystal ball would be handy.
cheers,
Helen
At 10:28 AM 13/06/2003 +1200, you wrote:
>However, I would appreciate your thoughts on how IBO might evolve forSorry if you got the impression that I'm deciding the direction of IBO! I
>cross platform use. Kylix is obviously one possibility but its future
>seems to be uncertain. What about .NET? I haven't looked into .NET in any
>detail yet, but I understand that it offers a path for cross platform
>development, so is there likely to be an IBO for .NET?
did the conversion of IBO to Kylix for Jason, but I'm in no way
instrumental in determining the course of IBO's evolution. Jason has
consistently required that the IBO-K data access follow the IBO for Delphi
model closely, and this has not been at all difficult to achieve.
With the native IBO data-aware controls, it's a different story. There are
problems with data-aware controls having the level of sophistication
implemented in the native IBO controls, which are going to need low-level
access that's currently not implemented in Kylix, or not covered by Borl's
licensing agreement regarding QT, or both. This seems to indicate a
significant investment in developer time and external QT licensing that the
potential market and the apparent flakiness of Kylix's future might rule out.
My thinking for now is that the IBO-K beta data access is fine for server
layers like yours, where the need for data-aware controls is minimal and/or
considered an undesirable cost in terms of resource usage. For server apps
- even with a thin GUI console - the architecture of native IBO data access
(as contrasted with the TDataset-compatible) lends itself strongly to
actual requirements, i.e. a non-interactive interface, or one that would be
realised most efficiently with the thinnest of non-data-aware controls for
display and input. It's the way we write thin console GUIs on Windows already.
There just doesn't seem (at present) to be the demand for Linux GUI clients
- apart from the requirement for Borl Dev Support personnel to create
gee-whiz, unreal-world demo apps on their laptops for Borcon events, and
the prevailing demand for a sophisticated, interactive GUI client for
newbie Linux Firebird admins who have cut their Firebird/Interbase teeth on
Windows with miracles like DBW and IBExpert.
The former is a "swipe" :-) but the latter could go in one of two
directions: the Windows emigres learn to love the directness and speed of
the command shell and the benefits of not having an X server competing with
the database server; or the Linux stalwarts en masse throw away their
insane prejudices ;-) about resource-consumption and get a predilection for
GUIs. (After all, I found KDE and wine ran *much* faster when I upgraded
my IBM 686 box with 128 MB RAM to a Duron 850 and 512 Mb, LOL.).
Getting back to "serious"...why wine? Well...umm...the Kylix IDE is a
Windows application.
A crystal ball would be handy.
cheers,
Helen