David Van Couvering wrote: > Is it worth considering finding some way for the embedded and client > drivers to share some code, so that the only real difference is that > the network one is sending its commands over the wire? This again > broaches the topic of veering away from DRDA... > >> Well hopefully the client gets thinner and thinner and the Derby embedded behavior gets exposed more. Ideally we are just looking for a remote execution and share code that way. I found this with my fix for DERBY-250. Rip out a bunch of code, fix a few bugs and increase client/embedded compat. Protocol limitations make this hard sometimes but in those cases I don't think a common JDBC implementation api is going to help, although some of the code certainly might as you have found with your localization project.
Where I think there are great opportunities for code sharing is in the handling of the protocol, especially the core duplications in client and server. You will see great similarities in Request.java and DDMWriter.java, Reply.java and DDMReader.java. and the parsing and writing of DDM Objects could be generalized for both. This is an area where I think we could most realistically have a well defined internal API, since conventions could be set and adding support for a new codepoint or datatype wouldn't cause any problems with jar mixing. The big thing is that I don't know how we would enforce backward compatibility in an open source environment. Some of the methods are tested explicitly in the protocol tests, but I could easily see a patch that just removed those tests slip through the cracks or new tests not getting added for new methods. I am still hoping a less risky means for code sharing presents itself. Kathey
