David Van Couvering wrote:
Hi, Jeremy, I like your idea of a "revolutionary" branch but (a) have no
idea how to set one up and (b) I don't think I have the "karma" yet to
do it.
a) is easy, just svn copy what you need to a suitable location under
'branches' and merge in your local changes. When the revolution is over
the branch either gets merged to trunk or deleted
To do that you need b) which is blocked waiting for root to create your
account.
I also was planning to do what you call "small but crucial refactoring."
First glance was not that promising though. I have been able to keep
out all the storage-related services, for the most part.
This really isn't about the embedded JDBC driver being tied to the
engine. It's more that the services themselves have lived a long life
under the assumption that they're running within the engine.
Which services are involved and can we isolate them? I would have
thought that the JDBC code could use a form of "in-VM" transport to
separate itself from the engine at a much higher level than the storage
level.
I would also wonder if there is a need for an "in-VM, cross-classloader"
configuration that would allow multiple applications to use different
JDBC versions but a common engine. I can see use for that when Derby is
embedded in an IDE like Eclipse or in an appserver where the engine is
running separate from the applications (e.g. different protection domain).
--
Jeremy
