db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: Modular build, was: VOTE: Approach for sharing code
Date Wed, 14 Sep 2005 18:17:47 GMT
Hi, Kathey.  My responses below...

Kathey Marsden wrote:

>David W. Van Couvering wrote:
>>Hi, Kathy, thanks for your email.  The timing is actually pretty good,
>>I was just talking with Francois trying to understand his concerns
>>After quickly describing the two approaches, I'd like to summarize the
>>experience/impact of these approaches from the perspectives of the end
>>user, the developer/maintainer, and the test developer/runner.
>Thank you David for the summary.  I thought "modular build"  meant 
>adding more jars,  so it was good to have that cleared  With Approach 1
>I personally am not too keen on the new ordering requirements,  testing
>requirements, or the potential for regression with the versioning scheme.
Note that we already have to do compatibility testing between client and 
server because of protocol changes.  But yes, this does increase the 
amount of testing we have to do.

The ordering requirements are for a very small subset of users.  For 
most users, ordering does not matter at all.

The regression question to me is the clincher.  If we just are not able 
to drop in a new version of Derby that could cause existing code to 
break because of their classpath order, then Approach 1 is just not 
feasible.  I am hoping we could document this change and the users to 
whom this is important could with very little effort adjust how they set 
up the order their jars are loaded.

In general I am concerned we are making architectural compromises for a 
small subset of customers.  One of my managers at Sybase once told me 
his priorities for making decisions around changes to a product: first 
the product, then the customer, then the engineers.  What he meant was, 
you don't want to compromise the overall "solidity" of the product for 
the sake of a small set of customers.

>For the USER EXPERIENCE  for either approach, how much  growth do you
>anticipate in the client due to code sharing  with the first round of
>what you want to share and a guesstimate of how big it might get if we
>utilize all that you think the client should use from  the engine?   
>The earlier thread on the size of the common jar file
>made it sound significant. 
That thread was assuming I was migrating the entire Monitor/Service 
architecture over into common, and it was getting a bit big.  This is 
not necessarily going to be required.  I have some thoughts, not yet 
fully gelled, about how we might be able to introduce a lightweight 
service architecture into common, and have this be compatible with the 
heavier-weight service architecture currently in the engine.

I'd like to understand what requirements we have for the footprint of 
the client jar.




View raw message