David Van Couvering wrote:
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.
For all the reasons above, plus others, I think this is a good idea.
--
Jeremy
