Re: Hessian 2

From: Scott Ferguson <ferg@xxx.com>
Date: Thu Jun 22 2006 - 08:44:10 PDT

On Jun 20, 2006, at 10:47 PM, Petr Gladkikh wrote:

> switch (leading-byte) {
> 'I': parse_integer // returns integer
> 'i': parse_var_integer // returns integer
> 'R': parse_reference // returns back reference
> 'r': parse_var_reference // returns back reference
> }
>
> Where procedures whose names starting with "parse_var_" interpret next
> byte as containing byte-length and portion of bits. In order to reduce
> number of bit-shifts that portion of bits should represent higher
> ones.

I'm not sure I understand how that would help. The current proposal
has the number of bytes needed encoded in the first byte:

    0x01 - 8-bit integer
    0x02 - 16-bit integer
    'I' - 32-bit integer

We could add a 0x03 - 24-bit integer, but I'm not sure how important
those numbers are.

So the overhead is a constant single byte plus the number of bytes
needed to write the data.

We could combine the ideas into something like:

   0x10 - 0x1f - 12-bit integer

That would allow integers from -2048 to 2047 to be encoded in only
two bytes instead of three. Is that more of what you're thinking?

-- Scott

> Respective parse procedure for variable length integer values would
> look like
>
> ILEN = 4 // length of "normalized" integer (4 for int or 8 for long)
> result = (byte array of length that can be interpreted as big-endian
> long or integer)
>
> b = read_next
> len = b >> 5 // get length in bytes
> result[0] = (b & 0x10) << 3 // store sign
> result[ILEN - len - 1] = b & 0x0f // store higher bits
> for i = (ILEN - len) to ILEN
> {
> result[i] = read_next
> }
> return result
>
> --
> Petr
>
Received on Thu 22 Jun 2006 08:44:10 -0700

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