At 10:18 PM 5/15/00 +0100, Phil Shrimpton wrote:

>
>If at all possible it needs to be separate from IB,
>for a number of reasons. Firstly, not everybody will want to use Java and
>will not require all the extra baggage. Secondly, and more importantly, I
>have lost count of the number of JVM/JDK's I have on my system, both in
>version numbers and 'makes', it seams every Java tool/development
>environment I have requires a different one, which is a pain in the backside
>to say the least.

A JVM is not inherently a large beast. I haven't either of the
open source implementations, but a JVM can be implemented in
100 KB (assuming AWT is omitted), which is less of a burden
of having to configure itwhen you need it. An integrated JVM
would live in the same shared library with the engine and use
a classes.zip in the InterBase install directory. The footprint should be
completely acceptable.

> Even Borland can't get it right, Visibroker for Delphi
>needs a different JDK to the main Visibroker product, so developing clients
>and servers on the same machine is not possible.

If Borland could get it right, InterBase-IV wouldn't be happening.

>
>Stored Procedures/Triggers - I think that with a broad range of UDFs around,
>a few minor language/feature enhancements would be enough in the short term
>(obviously Java would be great in the medium to long term), My two top
>enhancements would be the ever popular CASE statements, and the ability to
>reference field/table names as variables.

I concur with the case expressions and defer on the latter.

>
>'Scripting' - This should be client side, and should be an embedded
>scripting/macro language in ISQL (or whatever). The language should be
>platform independent and quick and easy to use. From personal experience I
>like Tcl, it has been put to good use in several tools I use, WinCVS is a
>good example. It (or whatever) would allow us to create very powerful
>condition based 'scripts' e.g. run sub-script A if condition B is met etc.
>It would also allow us to write small macros for speeding up everyday tasks
>like.
>

QLI has a very powerful scripting language with most of the features
referenced in previous posts. Borland buried it because it supported
GDML instead of pure SQL, but since most of the features people are
talking about are outside of SQL, this shouldn't be a problem. ISQL,
on the other hand, was written as a testing front end for dynamic
SQL and has no backbone whatsoever. ISQL is not a candidate for
extension.

Jim Starkey