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>): delivery
    temporarily suspended: Host or domain name not found. Name service error
    for name=non.net type=MX: Host not found, try again

attached mail follows:

On Tue, 2006-06-20 at 16:19 +0700, Petr Gladkikh wrote:
> Hello.
>
> I have looked at new Hessian grammar at
> http://wiki.caucho.com/Hessian_2.0_Grammar and have questions:

The description is known to be sketchy, by the way, it'll take a bit of
time before I can get a better description.

>
> 1. What does following notation mean?
> int ::= [x80 - 0xcf]

It's intended to look like a regexp character range, so it represents
the range from 0x80 to 0xcf.

> Does it mean that these numbers represent themselves?

Almost, it represents 32-bit integers between -16 to 63, i.e. code - 16

  So 0x90 represents the integer zero.

> If so what about other numbers?

All Hessian 2 values can be represented by Hessian 1 encodings. They
just have short forms.

For integers, all bytes can be represented by

  x01 b0

integers between -16 and 63 can be also be represented by

  x80 - xcf

shorts can be represented by

  x02 b1 b0

and all integers can always be represented by

  I b3 b2 b1 b0

like with Hessian 2.

So the integer 0 can be represented in 4 different ways:

  x90 - direct 0
  x01 x00 - byte encoding
  x02 x00 x00 - short encoding
  I x00 x00 x00 x00 - Hessian 1 encoding

Hessian 2 readers must return identical results for all 4 encodings.

> 2. I do not understand what following double encodings represent
> double ::= x06
> ::= x07
> ::= x08 b0
> ::= x09 b1 b0
> ::= x0b b3 b2 b1 b0
> ::= x0c b1 b0
> ::= x0e b3 b2 b1 b0

x06 - 0.0
x07 - 1.0
x08 - (double) byte-value
x09 - (double) short-value
x0b - (double) int-value
x0c - (double) (short-value / 256.0)
x0e - (double) float-value
D - Hessian 1 encoding

Since Hessian doesn't have a float type for example, the x0e encoding
lets Hessian 2 serialize floats with only a single character overhead.

The two encodings I'm least certain about are x0b and x0c.

> Double has to conform certain IEEE standard.

The 64-bit double does follow the IEEE. The other encodings are either
float or integers.

> So in these cases masks for mantissa, exponent and sign should be specified. It does not seem
> to be reasonable optimization since operations with such floating
> numbers will be inefficient.

In this context, the only operations are casts:

  (int) dValue
  (float) dValue

Compared to the I/O, it's a minor performance hit.

> 3. There is no protocol for querying protocol version from other
> party. So implementations of Hessian protocol itself will be
> incompatible. What for example implementation of version 1.0 would do
> if it receives one of these new codes?

Blow up. :)

The version number in the call becomes important.

All Hessian 2 implementations can read and write Hessian 1 encodings.

When a Hessian 2 server receives a Hessian 1 request (version < 2), it
must return a Hessian 1 response.

A Hessian 2 client will send a request to an unknown server encoded in
Hessian 1, but with the version == 2. A Hessian 1 server will return
the response in Hessian 1. A Hessian 2 server can look at the version
and return a Hessian 2 response.

If a Hessian 2 client knows that the server is Hessian 2, it can send a
Hessian 2-encoded request.

> Scott Ferguson wrote:
> > The next Resin snapshot will have a Hessian 2 implementation (probably
> > Friday)
> So I presume, Hessian 2.0 is not open for discussion anymore?

Hessian 2 is in the very early draft stage. We've barely started the
discussion.

Having a sample implementation for a draft specification is very nice,
especially for a specification which is trying to improve performance,
since it will let people get real results on actual data, rather than
just guessing based on theory.

>
> If it still possible to suggest something I would like to hear
> opinions about encoding I described earlier:
>
> >For "compressed" integer:
> >'i' nnnddddd dddddddd .... (up to 9 elements)
> >where 3 bits nnn represent number of bytes in the sequence - 1
> >and remaining bits ddd... contain bits of required integer.
> > For example:
> > 0xfff => 'i' 00101111 11111111
> > 0x3f3 => 'i' 00100011 11110011
> > 0x3 => 'i' 00000011
> > One reasonable variation here - instead of 3 use 4 bits for length
> > representation thus covering even those cases that are beyond 'long'
> > datatype.
> It is possible to make similar shortened versions for length, long,
> and ref.

Two issues.

First, there's no intention to change any Hessian semantics. So there's
no intention of adding any new datatypes. The Hessian type system has
proved adequate.

Second, Hessian is based on a byte-code, switch parser grammar. The
basic type of any data is determined by the first byte. So the main
Hessian parser is always just a big recursive switch, which is easy to
implement.

>
> It seems that Hessian 2.0 attempts to fill every gap in code space but
> IMO this is not very wise as it lefts no space for manoeuvre in future.

Well, in the 5 or so years that Hessian has been around, the only real
issues have been compression/encoding, some specification
clarifications, and Java implementation issues. There hasn't been a
request, for example, for any new datatype.

So I don't see any need to change the serialization semantics at all,
just add some compaction codes.

There are still plenty of bytecodes left open, just not the big blocks.

In the final spec, we could leave out the short-array encoding. But
that only really makes sense if we think there's another block that
could be more efficient. But if that's true, we should try to find out
now.

-- Scott

>
> --
> Petr Gladkikh
>
>
>