db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: Size of common jar file
Date Wed, 20 Jul 2005 16:17:12 GMT
Hi, Jeremy, I like your idea of a "revolutionary" branch but (a) have no 
idea how to set one up and (b) I don't think I have the "karma" yet to 
do it.

I also was planning to do what you call "small but crucial refactoring." 
  First glance was not that promising though.  I have been able to keep 
out all the storage-related services, for the most part.

This really isn't about the embedded JDBC driver being tied to the 
engine.  It's more that the services themselves have lived a long life 
under the assumption that they're running within the engine.

David

Jeremy Boynes wrote:

> David Van Couvering wrote:
> 
>> I'd like to understand the issues and concerns of the size of a common 
>> jar file.  Further inspection has shown that pulling in Monitor 
>> results in a large subset of the iapi and impl packages being pulled 
>> into the common area.  This will result in a larger footprint for the 
>> client.  Is this a showstopper?  I'd like to know before I spend too 
>> much time refactoring.
>>
> 
> It is concerning but I wouldn't classify as a showstopper. It does 
> perhaps imply more coupling than ideal between the embedded JDBC driver 
> and the underlying engine. Perhaps footprint can be constrained with 
> some small but crucial refactoring?
> 
> I would suggest checking what you have into a "revolutionary" branch so 
> that more people can be involved and help drive a solution.
> 
> -- 
> Jeremy

Mime
View raw message