Ok, will do - byte[] it is. Perhaps we should change the term "longstr" in the spec to "binary" or something similar. It would be less confusing.
Kim On Wed, 2006-12-20 at 19:08 +0000, Robert Greig wrote: > On 20/12/06, Kim van der Riet <[EMAIL PROTECTED]> wrote: > > > If we keep String, then > > String.getBytes() produces byte[], and > > new String(byte[]) gets a String. > > > > Will this work for security tokens? I am uncertain of the integrity of > > this conversion (but a test will soon prove it). > > String.getBytes() decodes using the platform default encoding, which > will probably work for most platforms but would almost certainly break > if there is a platform with UTF-8 as the default encoding (although I > am not aware of any). > > > Keeping String will open up general long strings > 256 chars as type > > String, or *must* we keep this byte[]? Your call. I *thought* we had > > gone over these types early in the project... but I can't find it. > > Do we have any cases where we need to send a true "long string"? I > think having it as a byte array makes sense for the current cases and > I think it was intended to be a byte array, despite the spec's odd > choice of name. > > RG
