Undelivered Mail Returned to Sender

This is the Postfix program at host caucho.com.

I'm sorry to have to inform you that your message could not be
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to <postmaster>

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                        The Postfix program

<johnm-hessian@xxx.net> (expanded from <hessian-interest-mailout>): Host or
    domain name not found. Name service error for name=non.net type=MX: Host
    not found, try again

attached mail follows:

Scott Ferguson wrote:

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

I think that this should be done at least for sake of consistency. And
  so an application designer would have freedom to choose most optimal
encoding for integer.

By the way, have you already thought how these fancy encodings will be
chosen during application execution? Seems there are two choices (with
some mixes in between): 1. Encodings are chosen during configuration,
2. An encoding is chosen by comparing an integer with a number of
ranges to choose shortest one (this of course incurs run-time overhead
on every write).

If a Hessian layer implementation is not so smart and encodings have
to be configured, the 3byte integer would be useful.

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

Yes. This is what I meant when said earlier that this kind of
compression is not the best. But it is better than original full_range
integers and longs.

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

Well, all I thought about is having more consistent scheme than it is
proposed now, but that seems to be complex if back compatibility is
required. This is a little bit of self-interest. I have already
implemented Hessian 1.0 protocol myself and if I will be implementing
version 2.0 it does matter whether I like it :)

Let me see. We now have following integer ranges (type bit prefixes
are in braces)

1001_0000 == 0 --> 1 byte

1000_0000 - 1100_1111 (10, 11 ?)
        == -16 to 63 (is "63" correct here?) --> 1 byte
e.g. 0 -> 1000_0000
        1 -> 1000_0001
        -1 -> 1100_0001
        -16 -> 1100_1111
        15 -> 1000_1111
        63 -> 1111_1111 right?

0000_0001 0x00 - 0000_0001 0xff (0000_0001)
        == -128 to 127 --> 2 bytes

0010_0000 0x00 - 0001_1111 0xff (0010)
        == -2048 to 2047 --> 2 bytes

0000_0010 0x0000 - 0000_0010 0xffff (0000_0010)
        == -32768 to 32767 - 3 bytes

0100_1001 0x00000000 - 0xffffffff (0100_1001)
        - int

0100_1100 0x00000000 - 0xffffffff (0100_1100)
        - long

Right? A table of all 256 bytes would be helpful to observe codes and
code-ranges that are proposed...

PS: If I'd allowed to fancy: we now have some prefix of variable
length that identifies a (type, length) pair. Such prefix is followed
by actual data bits. This closely resembles Huffman codes (see for
example here http://en.wikipedia.org/wiki/Huffman_codes). So a
protocol that would exercise a compression that is close to optimal
could send a preamble that describes prefix->(type,length) mapping and
then use it. So every application could choose what suits it best. It
can for example choose encoding for 2-bit integer or it may even
exclude some types that are not used or introduce new ones using some
"user-defined" type codes range. For Hessian 1.0 such preamble would
take about 50 bytes.
This is more of joke than a proposal, just saying :)

--
Petr