Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
Date: Tue, 16 Aug 2005 15:31:56 -0700
From: David Van Couvering <David.Vancouvering@Sun.COM>
Subject: Re: sharing code between the client and server
In-reply-to: <43026546.50602@sun.com>
To: Derby Development <derby-dev@db.apache.org>
Message-id: <4302695C.9050200@sun.com>
MIME-version: 1.0
Content-type: multipart/mixed; boundary="Boundary_(ID_GhzSqMTWwhR+ckGm9iMwWw)"
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
References: <43026546.50602@sun.com>

This is a multi-part message in MIME format.

--Boundary_(ID_GhzSqMTWwhR+ckGm9iMwWw)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT

You go, Rick!  I think the edge case is going to bite you, though.  I 
don't think you can wave your hands and say customers can just write a 
classloader to fix the problem.

If I remember correctly, the motivation for the edge case was to allow 
different versions of the network driver and embedded driver running 
next to each other.

I think this was motivated by some IBM customers.  My questoin is: is 
the real motivation for compatibility between client and server?  If so, 
it seems to me that what you really want is for a new version of the 
network client driver to be backward compatible with an older version of 
the server running elsewhere, or, vice-versa, a newer version of the 
server to be backward compatible with an older version of the client.  
This was managed at Sybase with the TDS protocol using a handshake at 
login time where the client and server agree at what version of the 
protocol to run at.  Perhaps this is what we want to do here.

If the motivation was something else, I'd like to understand it better.  
Dan D. was the main person who brought this up.  Is Dan back yet?

Thanks,

David

Rick Hillegas wrote:

> When we last visited this issue (July 2005 thread named "Size of 
> common jar file"), we decided not to do anything until we had to. 
> Well, I would like to start writing/refactoring some small chunks of 
> network code for sharing by the client and server. My naive approach 
> would be to do the following.
>
> o Create a new fork in the source code: java/common. This would be 
> parallel to java/client and java/server.
>
> o This fork of the tree would hold sources in these packages: 
> org.apache.derby.common...
>
> o The build would compile this fork into 
> classes/org/apache/derby/common/...
>
> o The jar-building targets would be smart enough to include these 
> classes in derby.jar, derbyclient.jar, and derbytools.jar.
>
> As I recall, there was an edge case: including a derby.jar from one 
> release and a derbyclient.jar from another release in the same VM. I 
> think that a customer should expect problems if they mix and match jar 
> files from different releases put out by a vendor. It's an old 
> deficiency in the CLASSPATH model. With judicious use of ClassLoaders, 
> I think customers can hack around this edge case.
>
> I welcome your feedback.
>
> Cheers,
> -Rick


--Boundary_(ID_GhzSqMTWwhR+ckGm9iMwWw)
Content-type: text/x-vcard; charset=utf-8; name=david.vancouvering.vcf
Content-transfer-encoding: 7BIT
Content-disposition: attachment; filename=david.vancouvering.vcf

begin:vcard
fn:David Van Couvering
n:Van Couvering;David
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:david.vancouvering@sun.com
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard


--Boundary_(ID_GhzSqMTWwhR+ckGm9iMwWw)--