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.
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.
David
Jeremy Boynes wrote:
David Van Couvering wrote:
I'd like to understand the issues and concerns of the size of a common
jar file. Further inspection has shown that pulling in Monitor
results in a large subset of the iapi and impl packages being pulled
into the common area. This will result in a larger footprint for the
client. Is this a showstopper? I'd like to know before I spend too
much time refactoring.
It is concerning but I wouldn't classify as a showstopper. It does
perhaps imply more coupling than ideal between the embedded JDBC driver
and the underlying engine. Perhaps footprint can be constrained with
some small but crucial refactoring?
I would suggest checking what you have into a "revolutionary" branch so
that more people can be involved and help drive a solution.
--
Jeremy
