db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: [jira] Updated: (DERBY-289) Enable code sharing between Derby client and engine
Date Wed, 16 Nov 2005 17:06:28 GMT
David Van Couvering wrote:

>
> If anybody has a brilliant idea for a design pattern that makes
> building forward-compatible code more readable and less complex,
> please send those cards and letters out.

David don't think this is brilliant , and  it is an old idea.  Would it
be ok for the  build to copy the message file into a separate name space
for client and server so there are no shadowing issues and no special
maintenance needed.  I know that there were objections to this for java
files but would it be so bad for the message property file? 

I think the framework is suitable for sharing well established, stable
interfaces but is too unwieldy for something as volatile as messages. 
The package.html says a message change or addition is a non-forward
compatible change and later says non-forward compatible changes
"must be well-justified, requires consensus approval and can only occur
at major release boundaries".    This is not realistic for a message change.

BTW,  so far in reviewing the patch, this is the only thing that comes
close to a show stopper for me. I'll get my other comments in by Friday.

Thanks

Kathey

P.S.
I had actually envisioned that we would keep just one message file and
encode whether the message was client, server or both in the message id
and then the build would separate out the client and server messages. 
That way there would still just be one file for translation and it would
be parallel to our single SQLState.java.  This is untried but just an idea.




Mime
View raw message