Thanks, Dan. I would like to know if we need to have a vote on the
overall principles of shared code or if people just want to see an
examlpe implementation. I am fine either way, although personally I'd
like to make sure we agree on the principles before I spend too much
time on an implementation.
I would say if I see at least two committers besides me saying they want
a vote on the principles, then I will send out a proposed wording, and
then we can discuss and do a vote. Otherwise, I will work on an initial
implementation with some small set of messages migrated over to the
shared component environment that demonstrates the framework, and submit
*that* for a vote.
Thanks,
David
Daniel John Debrunner wrote:
Rick Hillegas wrote:
I hope we're not talking past one another here. It's so easy to do in
email. I think we may agree on the following points:
o There is an existing problem when you mix two Derby-enabled
applications in the same vm.
o David's proposal increases our customer's exposure to this problem.
However, we may part ways on the following points:
o How significant that extra exposure is.
o Whether the benefits of code sharing justify that extra exposure.
That's a good summary.
I thought the last set of principles (the ones without the 'must use
classloader') took a good approach to minimize the exposure.
I think we should move forward on shared code, I think we all know it's
needed at some point. If we reject shared code now, then how do we get
to text indexing, xpath/xquery etc. I don't want to waste my time
writing text search code when Lucene exists.
I think the principles are good, especially this one:
'This implementation will not have any significant impact on jar file
size or otherwise affect product distribution or usage. '
though, probably it should say 'Any implementation will ...', or 'Code
sharing will ...' since the vote is on the principles, not an
implementation.
I think though, that we do need to address Kathey's concerns, her ideas
about logging different versions etc. are all useful. And we do need to
be ever vigilant on the usability of Derby.
Let's have some shared code, so that we can see what problems it creates
and then solve them.
Most likely any code we do affects usability in some way, and in some
cases we have to analyze the risk and see if the value out-weighs the risk.
Dan.
PS. this post was brought to you by too much Peet's coffee in the
afternoon ...
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
