On Dec 3, 2007, at 2:19 PM, Ben Hood wrote:

>
> Why do you need byte, char and short?

I wasn't thinking properly.

I do need to serialize and deserialize Byte and not have it magically  
transform into Integer (e.g. in the case where it's stored as an  
Object).  It's a rare case, but does need to be handled, since  
Hessian turns out to be very good as a java.io.Serialization  
replacement.

However, there's no need to modify the protocol.  The implementation  
can just serialize Byte into an object with an integer value, e.g.  
with type = java.lang.Byte.

> 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:

Right, which is why I was holding off from putting it into the spec,  
but just didn't go the final step and make Byte/Float into objects.

> Furthermore, I think that dropping the xml encoding from the spec was
> a good idea.

Yep.  It was really only added because Hessian was first created at  
the very top of the XML hype.

> 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.

True, but languages like PHP got into big trouble by not handling  
unicode properly :)

> 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.

I'll need to think about this.  Unfortunately, I'm not sure when  
we'll get the time to work on a TCK.  It would be very handy,  
though.  Hessian is simple enough that you can do comprehensive testing.

-- Scott

>
> Anyway, sorry about the rant,
>
> Ben
>
>
>
> _______________________________________________
> hessian-interest mailing list
> [email protected]
> http://maillist.caucho.com/mailman/listinfo/hessian-interest



_______________________________________________
hessian-interest mailing list
[email protected]
http://maillist.caucho.com/mailman/listinfo/hessian-interest

Reply via email to