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 versions. Anyway, I'll start with upgrading all of the jdbc class javadocs (except DatabaseMetaData) tonight. Cheers, Campell ----- Original Message ----- From: "Fred Toussi" <[EMAIL PROTECTED]> To: <[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, the > 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 (yes, > it will be over the pond RSN) needs the documentation updates I discussed > and there are improvements in setObject() functionality. Obviously both the > 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 Mike > is working on. Sometimes it's better to get it done first and discuss later. > > 3) My view of javadocs priorities is as I said before, JDBC first. > > Fred > > _______________________________________________ hsqldb-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hsqldb-developers
