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
better.
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
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200507.mbox/[EMAIL
PROTECTED]
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.
Thanks,
David
Kathey
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
