Kathey Marsden wrote:
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.
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.