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: Thu, 21 Jul 2005 15:53:05 -0700
From: David Van Couvering <David.Vancouvering@Sun.COM>
Subject: Re: Size of common jar file
In-reply-to: <42DF40D5.8050605@debrunners.com>
To: Derby Development <derby-dev@db.apache.org>
Message-id: <42E02751.8020601@sun.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6)
 Gecko/20040113
References: <42DD6B93.2010601@sun.com> <42DE7754.5090803@apache.org>
 <42DE7908.5020508@sun.com> <42DF40D5.8050605@debrunners.com>

Hi, Dan, I've been thinking a lot on what you have to say here.  When I 
first looked at this, I noticed what the tools and network server were 
doing for internationalization, and considered duplicating that approach.

But the original motivation was not just internationalization of 
messages, but also the use of SQL States that the exception handling 
framework in the engine does so well.  Currently the network driver set 
SQL State to null for all its exceptions.  I can also see a lot of use 
for other services in the client, such as the sanity service, the timer 
service to support timeouts, the crypto service to support pluggable 
encryption of data across the wire, some of the utilities in iapi.util, 
etc.  And what if we want to have a common logging/tracing framework, or 
if we standardize on some kind of JMX framework?  What if we want to add 
J2SE 5 features into the client code -- will we have to build our own 
component model there to support pluggability?

And just in general, it bothers me that we basically have a situation 
where we can't share code, and so the client code has to be written 
independently of the engine, cutting and pasting as need be, as if it 
were a different product altogether.

So although it would be fastidious and I suppose "practical" of me to 
just cut and paste, I really would like to see if we can make this work. 
  I feel it would create some leverage that will be very helpful moving 
forward.

But I also don't want to put a lot of work into something that will 
ultimately get voted down by the community.  So I'd like to hear what 
others have to say, and I will most happily bow to the will of the group.

Thanks,

David

Daniel John Debrunner wrote:

[snip]
> 
> 
> David, you may want to step back and see what you are trying to do. I
> think the original goal is to have the messages/exceptions localized
> from the client.
> 
> If you look at the other Derby code you see that for message handling
> each time the original code (for the engine) has been cloned so as not
> to share it. Now cloning/copying code is generally bad, but this is
> pretty simple & stable code.
> 
> So my viewpoint you seem to be putting a lot of effort in for very
> little gain in value, most likely especially when you see that the exact
> model used by the engine may not be well suited to the client. The
> engine hashes its messages into 50 message files, so as not to have a
> huge Properties object in memory for the messages. Now I would expect
> the client to have few messages so hashing into separate files may not
> be worth it.
> 
> So in summary, a shared code plan seems to be a lot of work, introduce
> several problems and solve little.
> 
> Dan.
>