Re: Hessian 2

On Jun 21, 2006, at 10:33 AM, Thomas Wang wrote:

> Scott Ferguson wrote:
>
>> http://wiki.caucho.com/Hessian_2.0_Grammar and have questions:
>
> I took a look at the specification. These are my feedbacks:
>
> Int taking up 0x80 to 0xcf seems excessive.

Possibly, see below.

> Don't you want to keep some un-used codes for future expansion?

I wasn't planning on it, but it might make sense. We might learn
more about better code distribution in the future.

> I have similar comments for Long's use of 0x20 to 0x3f.
> These consecutive unmapped ranges are very valuable. We should
> conserve them.
>
> Similarly I am not sure if reserving 0x10-0x1f will get you much
> more compression since the type and length fields already
> have some compression short-cuts.

True. That's the one that seemed most sketchy (also the x/256 for
double although that's just one code, and I'd think values like 0.5
would be fairly common.)

How about the following:

   0x80 - 0xaf - 32-bit integers between -16 and 31
   0xb0 - 0xcf - reserved for future (would make extending to 64 easy
if it proved useful.)

   0xd0 - 0xdf - 12-bit integers (using Petr's idea)

   0xe0 - 0xef - 64-bit long between -8 and 7.
   0xf0 - 0xff - reserved for future (would make extending to 23 easy
or 12-bit longs)

   0x00 - 0x0f - strings of length 0-15
   0x10 - 0x1f - reserved (makes extending to 31 easy)

   0x20 - 0x2f - binary of length 0-15
   0x30 - 0x3f - reserved (makes extending to 31 easy, although I
doubt it would be a win)

The single-byte codes would be reassigned from 0x40 - 0x80 in the
unassigned values.

> Are the double compressions IEEE compliant, both on input and
> output?

Sure. The IEEE double has a 53-bit mantissa. A 32-bit integer fits
easily into that space.

> Seems that if you can do float, then it's already a win.

True, but I'd expect small integers stored in doubles would be
common. float itself is only a win if the application is actually
using a "float", because any non-trivial double/float would differ in
the least-significant digits. We could kill the 32-bit integer
encoding, and leave only the 8-bit and 16-bit and float.

I'll see if I can get a snapshot out fairly soon so people can
experiment. These kinds of encoding tradeoffs would really benefit
from real-world data. Artificial loads are almost worthless. And
there's no rush to finish the spec. We can take time.

-- Scott

>
> Thomas Wang
>
>
>
Received on Thu 22 Jun 2006 10:21:17 -0700