Sounds good. Once we have got the 1.7.0 release out, we'll put the spec together and decide on packaging to get the two MetaData packages out. Looking forward to the updated JDBC docs for 1.7.0.
Fred ----- Original Message ----- From: "Campbell Boucher-Burnet" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "Fred Toussi" <[EMAIL PROTECTED]> Sent: Sunday, March 31, 2002 3:03 AM Subject: Re: [Hsqldb-developers] JavaDoc Comments > 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 _______________________________________________ hsqldb-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hsqldb-developers
