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.
