db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: [jira] Updated: (DERBY-796) jdbc 4.0 specific Blob and Clob method support
Date Thu, 16 Feb 2006 21:37:27 GMT
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 

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.


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

View raw message