RE: [Firebird-devel] How to start hacking on ISQL?

[Claudio V. C. <cv...@us...>]

Peter Jacobi wrote:
> Dear All,
>
> I just wanted to start making an experimental version
> of ISQL, but I'm rather disturbed by one thing:
>
> Why does ISQL depends on large amounts of the
> Firebird Server source tree instead of being a normal
> client app, using only the the public API?

Because
- it was never intended to be a user tool... but it became a user tool;
- they (Borland) thought it would be better to enhance it instead of
updating qli;
- it's better to take some values from the engine instead of having to sync
them with separate files. However, it would have been enough with including
some headers. It can be done because it's not a third party tool, so a bit
of overlapping can be tolerated;
- other dbs have an isql utility, so this is probably how the thing became
public... someone must have thought qli was pure GDML.

Don't expect those past decisions to be coherent. As former Borland CEO
Delbert Yocam said once, "Borland is not a database [maker] company". A dev
tools company doesn't have to be wise on db internals, specially at the
management level.

But ultimately, is the current way it works an obstacle for you? Please
explain. If you want to lose time in it, you may consider replacing the damn
allocator by a proper C++ memory management, although flagging unfreed
memory is never bad (one thing the allocator does, I think). Isql has some
extra commands when you run the debug version.

C.