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
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Naka
http://www5.ocn.ne.jp/~tomohito/TopPage.html
*/
----- Original Message -----
From: "Kathey Marsden" <[EMAIL PROTECTED]>
To: "Derby Development" <[email protected]>
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
