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 Jun 22, 2006, at 11:15 AM, Thomas Wang wrote:

> I think if Hessian 2.0 is to be a drop-in replacement for Java
> serialization,
> it will need to have support for "byte", "short", and "float" data
> type.

It's not intended to exactly replace Java serialization.

The interop with other languages is important, so it's important to
keep the number of datatypes simple.

In practice, the missing byte and short are generally less important
than you'd guess. If the object is a field, like "byte foo", then
the deserializer can do a (byte) readInt().

The case where Hessian is lossy for Java is when you store Byte
objects into an Object, like an ArrayList. But that can generally be
avoided when the application is designed.

> Java 5 support is also required.

True. I've just added a bug report.

I think the Hessian 1.0 encoding would look like

   M t .. foo.Color
       S .. name
       S .. red

In the compact form, the definition and first enum would look like

   O t .. foo.Color
       x91 -- length = 1
       S .. name
       S .. red

And any additional enums would look like

   o x91 S .. blue

> If you looked at the meta data class for Hessian, it is obvious
> that the
> overloading rules of Hessian are different than Java. I would
> focus more
> on Java compatibility instead of compression. If you can't drop-in
> replace
> ObjectInputStream, it doesn't matter that Hessian can compress better.

I'm not sure I understand. Can you explain more?

> But getting back to compression, when I tried to use Hessian to
> serialize
> Java objects, the repeating emission of identically named class names
> popped out at me. I suspect fixing this issue does not require a
> new syntax.
> Just moving the type name to within the list or map structure
> should do it.

I'd think that would change the syntax. The new O,o syntax fixes
that problem. It's really nice how compact a second object instance
is. The overhead is only 2 bytes and then the size of the fields.

> I abandoned Hessian serialization when I hit on an issue with Java
> 5 enums.
> It seems too risky to write custom serializations; I could have
> spent 2 weeks
> debugging various quirkiness that comes up.

Yep. enums are something we should take responsibility for.

> So I decided to layer ObjectOutputStream under Hessian. All object
> arguments
> and results are
> serialized with ObjectOutputStream. A 'j' prefix precedes every
> such objects.
> An exception is prefixed by a 'J'. An ObjectOutputStream reset is
> performed
> at the beginning of every remote procedure call. I am not sure if
> Hessian
> can synchronize the dumping of the object cache as easily.

If the reset method isn't there, it's easy to add. reset() just
involves clearing a few maps.

-- Scott

>
> Thomas Wang
>
>
>
>