Bryan Pendleton <[EMAIL PROTECTED]> writes: > Dyre Tjeldvoll (JIRA) wrote: >>> A solution is to keep the commonly used SQLStates as byte[] constants that >>> can be inserted into the message with writeBytes(). > > I think that the solution shows great promise, but the patch > that you provided seems too "open coded" for me. > > It seems to me that the recently-added DRDAString class could > be used as the encapsulation vehicle for this String/byte[] > caching stuff, so that the bulk of the DRDA code didn't have > to be so involved in the details of when to use the string and > when to use the byte array. > > So instead of seeing a bunch of changes like: > > - writer.writeString(server.prdId); > + // Write the byte[] constant rather than the string, for efficiency > + writer.writeBytes(server.prdIdBytes_); > > which seems to mean that we'd have to maintain constant vigilance > into the future to make sure that we know when to use the String > versus when to use the byte[], it seems like we should turn an > object like server.prdId into a DRDAString, and then let DDMWriter > and DRDAString work out the details themselves about whether to use > the String or the byte[]. > > Does this make any sense? Am I barking up the wrong tree?
It makes sense, but DRDAString uses a CcsidManager to convert between byte[] and String. Currently, the only implementation of CcsidManager is for ebcdic, while the message Dyre is working on is sent in UTF-8, I think. In that case we need a UTF8CcsidManager. -- Knut Anders
