Well, this is an interesting wrench you have thrown in here, Jeremy. I
personally have always been a believer in the scheme you suggest, with
modules of code being built independently rather than a single
monolithic code base. It allows for greater flexibility, but it does
require a lot more discipline in terms of version compatibility. This
is the way Solaris works, for instance, and they have been quite
successful at it. But you should see the level of rigor they apply here
at Sun to make sure that works. Before this level of rigor was applied,
Solaris was a nasty ball of yarn indeed.
Now, we do have a guide for us in this approach. Jakarta Commons is a
collection of independent modules that are released independently, and
which must meet strong compatibility rules. Take a look at their
versioning guidelines here:
http://jakarta.apache.org/commons/releases/versioning.html
The question is, what are the benefits of the approach, and do they
merit the rigor that we would have to follow to make sure things don't
break? I have to think about this myself. What do others think?
P.S. Jeremy I don't understand why separate classloaders are needed to
work with different versions in the same VM, if we meet compatibility rules.
David
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
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
