Re: Hessian C++ library

Scott Ferguson wrote:
> That's fantastic!
>
>> - GZIP support both in the client and in the server (the hessian
>> server side
>
>
> I like this idea, but the Hessian protocol should probably be enhanced
> to support it, e.g. a 'Z' or 'z' prefix to the hessian message would
> indicate that it's gzipped. Or possibly the initial 'r' should have the
> 2nd byte be a flags byte and have gzip as one of the flags.
>

Hi Scott,

Thanks for your quick reply !

Regarding the GZIP compression:
On the client it's trivial to test whether this is a compressed reply or not,
since the GZIP stream has it's own "magic" signature.
The hessian proxy (call-level) acquires the full reply (from the network) and
looks at the first two bytes. If those are the GZIP magic (0x8b1f) then it
decompresses the reply and passes that onto the lower-level decoding API; if
not, than it just passes the reply as is. The protocol level API checks for the
expected [r][MAJOR][MINOR] and so on.
Thus the compression is handled at a higher level then the actual Hessian
encoding, leaving it unchanged and oblivious to any compression or any other
processing.
I for one think this approach has the big advantage that it tends to minimise
interference with the data encoding and the protocol does not need any revisions
in order to add things like compression, digital signatures, non-SSL encryption
(many low level devices do Triple DES in hardware for instance and that
suffices) and maybe others.

>> - a hessian_proxy class that can be used to dynamically invoke remote
>> methods
>> - a servlet that piggy-backs on the default service servlet from
>> Hessian to
>> present a service interface when HTTP GET is used (sort of primitive
>> .NET asmx
>> style auto-doc).
>
>
> How does the GET encode parameters?
>

I'm afraid I've not managed to properly explain what it does.
At the moment the Hessian servlet processes POST by invoking into the configured
service and sends back a HTTP 500 error on GET.
What I've done is derive a servlet from HessianServlet and add an auto-doc-ing
feature on GET, while the behaviour of POST is passed on to super.service().
The auto-doc thing is actually an HTML page with the name of the service and
it's methods' signatures, generated through reflection.

>> The library also makes good use of STL and exceptions, and allows one
>> to use it
>> at both protocol and method call level.
>>
>> Hessiancpp has been developed and tested on both Linux (Fedora Core 2
>> x86_64,
>> Redhat 7.2) and Windows (XP, 2003 Server).
>>
>> Please let us know how to proceed. We'd like to have peer review of
>> the code,
>> while also being able to make changes; for this, a sourceforge project
>> seems the
>> way to go; on the other hand we'd like to see the C++ implementation
>> listed
>> together with the Java & Python ones on the Hessian pages at Caucho.
>> Licensing is also something that needs to be addressed; we'd like to
>> have the
>> code copyrighted but under an OS license, say LGPL.
>
>
> We would certainly love to link to it!
>

That's great, thanks !

> The cleanest solution would probably for you to create your sourceforge
> project and maintain ownership of it. That way you can choose the
> copyright that works best for you. We'll link to it from caucho.com as
> the C++ Hessian implementation.
>

Agreed. I'll set this up and get back to you on this.

> -- Scott

In the meantime, if we could continue the dialogue on my points above, that
would be great.

There's also a few other things that I may have some suggestions on, such as
optionally disabling stack traces on exceptions and moving the actual
service-thrown exception name in place of what currently reads
"ServiceException" (com.caucho.hessian.server.HessianSkeleton.java:145). These
changes combined would significantly reduce the size of an exception on the
wire. This may not be wanted for a Java client, but any other language has
little if no use for the stack trace and would not have to descend into it in
order to get the actual exception name if they need to base any decision on that.
At the moment we're circumventing this by having a service-specific exception
hierarchy and the top level exception class erases it's stack trace when the
getMessage() method is called, reducing the size of the reply.

Regards,

-- 
Radu-Adrian Popescu
CSA, DBA, Developer
Aldrapay MD
Aldratech Ltd.
+40213212243