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:

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