db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "TomohitoNakayama" <tomon...@basil.ocn.ne.jp>
Subject Re: [jira] Commented: (DERBY-458) Make it clear the difference between EmbedConnection and Networked Connection
Date Tue, 23 Aug 2005 14:31:25 GMT
Hello.


I read what Kathey wrote in series of mails as next.

The EmbedConnection and NetworkConnection are different existences at all,
because
EmbedConnection is existence which acts in engine and
NetworkConnection is just an existence of handle to EmbedConnection separeted from engine
by network.

//I wonder whether NetworkConnection can be just a handle to EmbedConnection, however I'm
just wondering it.

On the other hand, server side object and client side object , which compose NetworkConnection
,
seems to have similarity.
e.g. Request.java and  DDMWriter.java, Reply.java  and  DDMReader.java .
These code might be shared.


>Can you  close  out DERBY-458  and file the code or doc issue if it arises.
I see ... I will log contents of these mails (especially references which needs to understand
network implementation of derby ( 
Thank you :) ) in JIRA and close it.

Please give me time to put my brain in order.


Best regards.


/*

         Tomohito Nakayama
         tomonaka@basil.ocn.ne.jp
         tomohito@rose.zero.ad.jp
         tmnk@apache.org

         Naka
         http://www5.ocn.ne.jp/~tomohito/TopPage.html

*/
----- Original Message ----- 
From: "Kathey Marsden" <kmarsdenderby@sbcglobal.net>
To: "Derby Development" <derby-dev@db.apache.org>
Sent: Tuesday, August 23, 2005 9:01 AM
Subject: Re: [jira] Commented: (DERBY-458) Make it clear the difference between EmbedConnection
and Networked Connection


> 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?  This again
>> broaches the topic of veering away from DRDA...
>>
>>>
> Well hopefully the client gets thinner and thinner and the Derby
> embedded behavior gets exposed more.     Ideally we are just looking for
> a remote execution and share code that way.   I found this with my fix
> for DERBY-250.  Rip out a bunch of code, fix a few bugs and increase
> client/embedded compat.
> Protocol limitations make this hard sometimes but in those cases I don't
> think a common  JDBC implementation api is going to help, although some
> of the code certainly might as you have found with your localization
> project.
>
>
> Where I think there are great opportunities for code sharing is in the
> handling  of the protocol, especially the core duplications in client
> and server.   You will see great similarities in Request.java and
> DDMWriter.java, Reply.java  and  DDMReader.java.  and the parsing and
> writing of  DDM Objects  could be generalized for both.  This is an area
> where I think we could most realistically have  a well defined  internal
> API, since conventions could be set and  adding support for a new
> codepoint or datatype wouldn't cause any problems with jar mixing.
> The big thing is that I don't know how we would enforce backward
> compatibility in an open source environment.   Some of the methods are
> tested explicitly in the protocol tests, but I could easily see a patch
> that just removed those tests slip through the cracks or new tests not
> getting added for new methods. I am still hoping a less risky  means for
> code sharing presents itself.
>
>
> Kathey
>
>
>
>
>
> -- 
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.338 / Virus Database: 267.10.14/79 - Release Date: 2005/08/22
>
> 



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.14/79 - Release Date: 2005/08/22


Mime
View raw message