db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: VOTE: Principles of sharing code
Date Sat, 29 Oct 2005 00:02:51 GMT
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