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: VOTE: Principles of sharing code
Date Mon, 31 Oct 2005 15:21:07 GMT
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 ...
> 

Mime
View raw message