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 Mon, 12 Sep 2005 20:19:46 GMT
Well, we're at a bit of a standoff here.  What I'm looking for is a
nail-in-the-coffin data point that would move us in one direction or
the other.

Here are my feelings on the issue.  Although the cloning approach
helps us avoid having to maintain compatibility, my gut feel is that
it is a hack and it will come back to bite us in the future.  I also
think it's not extensible -- it's a particular solution to a particular
problem of sharing code between client and engine.  What if we want to
share code in other ways in the future?  We'd have to keep trying to
extend this model, making more and more copies.   I also don't like the
debugging model of the cloning approach, where what you're looking at
and debugging is not the "real" code but "shadow" code.  It just overall
feels like a bandaid type of approach; when I've gone for these types
of solutions in the past I've almost always regretted it (or somebody
else who had to deal with it four years later).

The module principle as Jeremy describes it, is a well-understood approach,
it's already in use within Jakarta commons, and has been used to great
effect in Solaris.  It's extensible, and it has been shown to be effective
in allowing a project to be more flexible and scale up better as a project
grows in size and complexity.  It's also in line with the approach we
already have in place with the engine code, with the Monitor and Service

That said, I recognize that it requires a certain level of discipline 
around version compatibility to make this scheme work.  For this reason, 
I think we should be careful how many "modules" we create.
I don't think it helps to take every subsystem and turn it into a module
unless there is a need for it to be used in multiple places.  For now I
would like to propose we stick with just the "common module" as the only
one; if necessary we can break this into smaller pieces in the future,
for example splitting out the DRDA code, but so far I don't see a need
for that.

So, unless someone can show me a nail that puts the module approach in
the grave, this is the approach I'd like to take.



Jeremy Boynes wrote:

> Kathey Marsden wrote:
>> Jeremy Boynes wrote:
>>> In that context, components that come to mind are engine, client, net,
>>> tools and common and external dependencies for consideration include
>>> logging, configuration and thread management.
>> What type of version  interoperability do you propose for these
>> components and how would that be managed?
> I think the same as what we have proposed earlier on this thread.
> The public interface for any component can only be extended at the 
> same major.minor level. So 10.3 may have stuff that 10.1 does not have 
> but a consumer built against 10.1 is guaranteed to work with any 10.X 
> implementation provided X >= 1. Any incompatible changes require a new 
> major version and no compatibility is implied.
> Implementation can provide version information about themselves and 
> about the interfaces they support; this might be through the Package 
> info or through some custom mechanisn. Consumers can query that and 
> adapt as appropriate.
> This applies within a single classloader; if a user needs a more 
> esoteric scheme within a single JVM then they need to isolate the 
> versions from each other by using different classloaders. I do not 
> consider this an unrealistic expectation given this is a non-trivial 
> case in the first place.
> One thing I think we should add is separation between in-VM client 
> (the JDBC implementation) and the engine implementation. This should 
> allow a program in one classloader to access an engine in another; 
> this may involve data copies which would make it less performant than 
> an in-classloader configuration but it will be better than using a 
> network connection which is the only option now.
> Across JVMs we support up-down compatibility across a wider spread of 
> versions but that can be done with the wire protocol and does not need 
> class-level compatibility.
> -- 
> Jeremy

View raw message