Hm. Logically I see your point, but I'm not sure I'm convinced. If I were to build a new JDBC implementation and I had an existing one in place, I would like to inherit as much as possible from the existing implementation and diverge only where there is a difference, rather than start from scratch, which is basically where things stand now. In our case, the difference between the two implementation should /solely/ be the fact that the interaction with the next layer of Derby - I guess that would be the SQL layer - is local or over the network. Everything else should be identical (xcept perhaps in cases where you would get a very chatty network interaction, and some communication efficiencies can be obtained).

Right now we are discovering major differences, and we could pick at them one by one, but I do wonder if there is a more efficient way and ultimately more maintainable way to accomplish this...

Thanks,

David

Daniel John Debrunner wrote:

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?

Possibly, but then you need common JDBC code that writes to a unified
internal api (say derby-db-api), and then there are two implementations
of derby-db-api, embedded and network.

Thus you have to define a derby-db-api that supports all the
functionality of JDBC.

The current approach is that derby-db-api is JDBC, and the two
implementations are the embedded  and client drivers.

Maybe an extra level of indirection would save some code, but at the end
of the day you still need two implementations of something, one for
embedded and one for client.

I just don't see this approach would be of much benefit.

Dan.


begin:vcard
fn:David Van Couvering
n:Van Couvering;David
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

Reply via email to