[Ijsql-devel] ToDo list brainstorming

[william g. <ww...@ts...>]

Here's a list of features that I'm thinking of; quite a few are the
result of some emails traded between Jukka and myself:

1) Swing gui as an alternative to the console; a friend of mine has
donated some Swing code from a nice gui db browser he wrote, so we can
start with that; it's in cvs now, in the gui sibdirectory.

2) Adding some config settings from the command line, ala Oracle's
Sql*Plus (i.e., setting column display lengths, directions to spool
output to a file / print que, ability to shell to an editor to edit
complex sql, then have it execute upon exiting the editor, etc.)

3) Adding stored procedure (CallableStatement) support

4) Expanding the metadata queries: right now the DatabaseMetaData
queries don't accept any parameters, so you can only invoke those
methods which do not take args (it'll be simple to implement the args)

5) Separating the "engine" code from the presentation logic; this
obviously goes hand in hand with #1 above, and will also allow the main
code's use in servlets, jsp, etc.  Maybe servlet and/or jsp interfaces
will become a feature as well?

6) Switchable connections to multiple db's.  This was Jukka's idea, and
he's working on this now; it'll be sort of like virtual consoles: I
might have a connection open to an Oracle db, then be able to switch to
another thread which is handling a connection to MySQL, etc.  Jukka,
jump in and correct me if I've misunderstood this feature ...

7) getting rid of the hard-coded Class.forName(drivername) stuff at the
begining; I'm leaning toward putting the driver classnames into a
properties file so they can be read in and loaded.  The version of code
that was checked in to cvs has this, but it's not been tested at all
(compiles ...   ;-)

8) bug fixes, as soon as we get around to logging bugs.  One irritating
one that I know of is that the tool crashes if there's a SQLException:
it should just print a warning and continue on, especially if it's
because of something like a typo in a query ...

9) Integrating in or writing an OQL (Object Query Language)
parser/interpreter, so that the tool will be able to handle non-jdbc
object repositories (such as the ObJectBridge project also on
Sourceforge).

10) we need a package name, as Jukka pointed out in his first email to
me.  I'm still not sure how that's going to work: if we do the standard
thing and reverse the domain name, it would be "net.sourceforge.ijsql",
but I don't know if we're allowed to use the sourceforge name.  I have
an inquiry in with support to get an answer.  If we don't get that
permission, we can use my domain, curiousmuse.com.

Anyone else have ideas?  Peter, you mentioned XA ...