Hi Robert,
> Supporting multiple encodings would be useful I think; if we don't
> support it then implementations that want to do that will just encode
> things in a proprietary way in an opaque byte array.
Yes, that's true, assuming that having both an ascii and default wide
encoding weren't enough.
=> > 2- The proposal mentions that the ASCII_STRING type should be prefixed
by
> a
> > 2-byte unsigned integer length (ushort). However, the current
> implementation
> > writes a four-byte length prefix. Also, why make this a two-byte length
> > while keeping a 4-byte length for wide strings?
>
> 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?
> > 4- Is the id for the BYTE type correct? I think the Byte datatype in
Java
> is
> > unsigned, right? If so, then the type code should've been 'B', not 'b'.
> no?
>
> No, byte is signed in Java.
Duh, I'm an idiot, you're correct.
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.
Obviously, I left some stuff as it was as to not to brake compatibility, and
the field types that were unimplemented in Java (like timestamp, decimal and
so forth) are still unimplemented in my code.
Tomas Restrepo
[EMAIL PROTECTED]
http://www.winterdom.com/weblog/
