Kathey Marsden wrote:
David W. Van Couvering wrote:

Thanks for the history, but you still didn't say what "AM" stands for???

I think it was abstract machine  (but don't hold me to that) which I
think is still kind of relevant. There is no protocol specific code in
there. All of that lives under net.  One could imagine there might be
one day be http or something else and all the generic code would still
live in am.
Right... AM was for Abstract Machine. The ideas was to isolate JDBC implementation from actual protocol code. It may be possible to implement NET package to use underlying embed JDBC code, so both embedded and client JDBC drivers could share AM code. But I hope I didn't re-ignite David's pet project of sharing code between client and embed drivers. :-)  While it is a good idea, I think underlying code sharing issues need to be resolved first, in my opinion.