>> When is this likely to be published? Is there going to be an >> announcement? > > I'm not sure. There are a few other changes we need to add (adding > Byte, Short, Character.) Probably in 1-2 months.
Why do you need byte, char and short? The reason why I am asking is because they not very often used and I feel that the power of Hessian is the trade off between simplicity and expressiveness. Furthermore, they are very Java/C/C++ - ish and stipulating them may make Hessian implementations in other languages more difficult. My suggestion would be as follows: 1. A byte can be expressed as a binary of length 1. 2. A char can be expressed as a string of length 1. 3. Int and Long encoding for small values get optimized to 8 or 16 bit encodings anyway, so there is IMHO no real reason to differentiate between Int and Longs in the first place, let alone Shorts. I would just have a general integer encoding with a maximum length of 64 bits and then let each language decide how it wants to allocate memory for each length. For a Short in Java for example, as far as I'm aware, most JVMs reserve 4 bytes anyway even though the compiler would narrow any assignment. Also there are few APIs that mandate Shorts. In fact, I think that the thought process that has gone into the Hessian integer encoding is testament to this observation. Furthermore, I think that dropping the xml encoding from the spec was a good idea. I think as well that this is made more interesting by the observation that not all languages distinguish (statically or dynamically) between Strings and raw binary data. Some languages use String notation simply as syntactic sugar to allocate a byte array. >>> >>> OK, that's fine. By that token would the above example use >> >> O x0b example.Car >> >> or >> >> O S x00 x0b example.Car >> >> to use the compact string encoding? > > Yes, thanks for catching that. > > I was thinking about how one would go about implementing a TCK for Hessian implementations. One idea did strike me - the guys at AMQP define the spec in terms of a parseable XML document, allowing implementors to generate a lot of boiler plate code in whatever target language they are interested in. I don't know how practical this could be for Hessian, but at least you could list byte arrays that map to specific types and object graphs, which is already partly there anyway. Anyway, sorry about the rant, Ben _______________________________________________ hessian-interest mailing list [email protected] http://maillist.caucho.com/mailman/listinfo/hessian-interest
