Except for the Locale code I infused into Trace, it should be very simple to
make a fat and slim distrubution.  I purposely set up DIFactory and the
pre-existing DatabaseInformation class for this, so that

1.)  different children of DIAbstractTableProducer can be selected at either
compile or connect time, or possibly even by setting a system property via
SQL at runtime through the use of DIFactoryPropertyInfo objects.
2.) little or no dependencies are created in pre-existing classes on the new
DIXXX classes, with Database and jdbcDatabaseMetaData being the exceptions
(Database registering aliases for the library methods of DIJdbcLibrary and
jdbcDatabaseMetaData defering directly to DIJdbcLibrary for local instances,
while performing CALLs to DIJdbcLibrary methods as SQL stored procedures
across the network for remote databases).

All in all, if the code for genrating the SYSTEM_SOURCE (on second thought,
should probably be called SYSTEM_BYTECODE) table in
DIDefaultSystemTableProducer and the org.hsqldb.clazz package are dropped,
the compressed class files for just my metadata patch take 61K, plus add an
extra 4K (compressed) to jdbcDatabaseMetaData.  Include the compresed size
of all the locale properties files (English, German, Italian, French,
Spanish, Portugese, Japanese, and Chinese for Trace messages, plus just
English for system table names and system table/column comments) at ~15K,
and the metadata patch comes in at 80K compressed jar space, without
obsfucation for size reduction.

(note:  If we are going to include the Locale stuff, we should probably put
out a call for someone to translate the system table/column comments to the
base language set I have provided for Trace messages, as well as verify my
Trace message translations, since I do not have either the time or the
language expertise to do this.  Perhaps we can make a final decision about
the keying before we embark on this, however?)

One can reasonably expect a 20-25% reduction to the class files after
obsfucation, resulting in a final size of ~ 65K for the whole metadata
patch, sans the clazz package based stuff
(procedure columns showing parameter names as declared in source,  and
tabular representation of the bytecode for all public static methods
accessible through class grants)

I think with a bit of work it will be possible to bring this down even
lower, as I am sure there are things such as services used across the DIXXX
classes whose functionality I have duplicated several times, local to each
class.  However, I think it is probably unreasonable to expect to be able to
provide all of the required JDBC results as system tables and continue to
provide the full DatabaseMetaData functionality (even if Locale is
abandoned) in less that 50K jar space additional to the 1.7.0 jar.  Oh well.

I have often thought that there were really too many methods in the
DatabaseMetaData interface and that their names are too long.  Most of the
DatabaseMetaData methods work essentially like properites, and as such I
really think the design should have been set up accordingly.  That is, a
smaller, more efficient and easier to implement DatabaseMetaData should have
had simply the methods: getBoolean(key,props), getNumber(key,props),
getString(key,props), and getResult(key,props).  But then it is easy to have
20/20 hindsight.  ;-)

Final note:  If we are going to distribute a fat and slim (or design and
production, if you will) versions of the metadata implementation, then we
should probably create and distribute jdbcDatabaseMetaData javadocs for both

Anyway, I'll start with upgrading all of the jdbc class javadocs (except
DatabaseMetaData) tonight.


----- Original Message -----
From: "Fred Toussi" <[EMAIL PROTECTED]>
Sent: Saturday, March 30, 2002 5:24 PM
Subject: Re: [Hsqldb-developers] JavaDoc Comments

> Thanks Campbell,
> 1) I am not concerned at all about commenting 1.6.1 and 1.4.x, otherwise
> what's the point of doing all the work to get 1.7.0 out.  As for the next
> release, we need a two-version (fat and slim) distribution because of the
> very large size of your much improved metadata. (To put this in context,
> JAR for the JDBC2 driver for one of the major RDBM's is over 500K in size,
> and that is just the JDBC driver, not the engine). So basically the new
> stuff will be a new driver, with its own documentation. The RC4 stuff
> it will be over the pond RSN) needs the documentation updates I discussed
> and there are improvements in setObject() functionality. Obviously  both
> big MetaData and small MetaData stuff share what is not MetaData related.
> 2) Sure, why not write something up and that will fit in with the stuff
> is working on. Sometimes it's better to get it done first and discuss
> 3) My view of javadocs priorities is as I said before, JDBC first.
> Fred

hsqldb-developers mailing list

Reply via email to