Scott Ferguson wrote:
> On Jun 22, 2006, at 11:15 AM, Thomas Wang wrote:
>>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?
Sorry, I was referring to the mangleClass method in AbstractSkeleton.java.
That implementation is not compatible with Java, since 'int', 'short',
and 'byte' are all mapped to 'int'. I was just pointing out that Hessian
is not designed to be a drop-in replacement to
ObjectInputStream/ObjectOutputStream based RPC. By 'drop-in' replacement,
I mean that the code was to work the instance I switch in Hessian
implementation. If I had to do a series of modifications to my existing
code base to make it work, it is definitely not a drop-in replacement.
You can infer that because of this limitation, Hessian may not be
attractive for bolt-on RPC uses in a legacy application, because changing
legacy code is costly.
It has now occurred to me that just having an 'int' type is fine, as
long as method arguments of 'short', and 'byte' are mangled distinctly.
The proxy and the stub just need to do some simple conversion to handle
these arguments correctly.
The way I implement method name mangling is to try 'no mangling',
'simple mangling', followed by 'full mangling'. I stop once every
method resolves uniquely.
Thomas Wang
Received on Fri 23 Jun 2006 11:16:20 -0700
This archive was generated by hypermail 2.1.8 : Thu Sep 28 2006 - 20:16:41 PDT