On 05/02/07, Tomas Restrepo <[EMAIL PROTECTED]> wrote:
Yes, that's true, assuming that having both an ascii and default wide
encoding weren't enough.
Yes. I think it depends on the data which encoding makes sense. For
primarily western characters, UTF-8 is obviously good whereas that is
less efficient for primarily eastern characters where you'd want
UTF-16.
> It was really to keep the overhead down since we send a lot of ascii
> strings.
Understood. But am I right in assuming the current implementation doesn't
honor that rule, right?. It also seems that the current java and .net client
code encode all strings as LONG STRING ('S') at this time, and that should
move over to use ascii strings by default ('c') right?
Yes, by moving to the new encoding proposal it would completely break
interop with existing clients so until it is ratified by the AMQP
group it was felt that keeping backwards compatibility to at least
some extent was desirable.
Given this, I've already built an initial implementation of the proposed
type system based on the original java code (with some obvious changes to
support the .NET code and type system). It also seems to be working (in that
at least the basic connection and message send/receive tests are working
against the java broker), though many more tests would be needed.
Excellent.
RG
