Re: Hessian 2.0

From: Tom Kaitchuck <Kaitchuc@xxx.com>
Date: Tue Jun 27 2006 - 10:28:07 PDT

Scott Ferguson wrote:
>
> On Jun 22, 2006, at 5:04 PM, Tom Kaitchuck wrote:
>
>> Hello all,
>> I have been working on adapting hessian for a project I am working on. I
>> have already created a modified version of com.caucho.hessian.io which
>> has performance enhancements, code cleanup, feature removal, and a
>> number of unit tests. I plan to continue to make improvements, but have
>> no intention of providing any support. If anyone would find this useful,
>> just let me know where to send the diff.
>
> Interesting. What performance enhancements did you find?
The major ones are:
In hessianInput there are sever sections of code that look like this:

      _chunkLength = (read() << 8) + read();
      ByteArrayOutputStream bos = new ByteArrayOutputStream();

      int data;
      while ((data = parseByte()) >= 0)
        bos.write(data);
      return bos.toByteArray();

However it is better to do:

      _chunkLength = (read () << 8) + read ();

      byte[] result = new byte[_chunkLength];
      _is.read(result);
      return result;

And in MapSerializer there is a section that looks like:

    Iterator iter = map.keySet().iterator();
    while (iter.hasNext()) {
      Object key = iter.next();
      out.writeObject(key);
      Object value = map.get(key);
      out.writeObject(value);
    }

But is better to do:

    Iterator < Map.Entry > iter = map.entrySet ().iterator ();
    while (iter.hasNext ()) {
       Map.Entry entry = iter.next ();
       out.writeObject (entry.getKey ());
       out.writeObject (entry.getValue ());
    }

>> I noticed that you have added some new types in the draft for Hessian
>> 2.0, but it is not clear from the WIKI what each of these values
>> actually represents.
>
> I added a new page at http://wiki.caucho.com/Hessian_2.0 to describe
> some of the draft ideas.
>
>> I would also like to specifically request that if
>> the comment period is not closed c/c++ primitives be supported, as I
>> will need to implement this anyway, and I would prefer not to break
>> compatibility.
>
> We just started brainstorming for Hessian 2.0. I'm guessing it will
> be at least 6 months before we make it final. No sense rushing in it.
>
> The goal is not to add any new types, merely compact representations.
>
> c/c++ primitives should already be supported, just in a somewhat
> wasteful manner, since you can encode a byte using I x x x x.
I was thinking more along the lines of supporting both *signed and
unsigned *versions of:
byte, short, int, long, long long, float, double and quad. The point of
signed vs unsigned is not that you could not encode the same data some
other way, but that a client should be able to query whether something
was sent as a signed or unsigned integer. Of course if the client calls
a hypothetical function getSignedInt(), they should get it is a signed
integer, regardless of what type it is in the datagram.
Received on Tue 27 Jun 2006 10:28:07 -0700

This archive was generated by hypermail 2.1.8 : Thu Sep 28 2006 - 20:16:41 PDT