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
