Not much is being ignited for me right now, I'm too busy just trying to
tie up loose ends before I go off the grid.
I totally agree, by the way, that such a project should wait until after
the code sharing infrastructure is worked out. That code is still
waiting in my sandbox for me to get back to it, hopefully post-10.2 and
post-baby.
I'm a little uncomfortable convert the top layers of the embedded driver
code over to use the AM code, as this code seems a little less baked to
me than the embedded code. I do like the idea of a single API, though,
as it would make it much easier to make the embedded and network client
drivers compatible.
Interesting what such a simple question will uncover.
David
Satheesh Bandaram wrote:
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.
Satheesh
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
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
