Re: Hessian PHP implementation

Scott Ferguson wrote:
> Actually, the Accept-Encoding would work just fine, and letting Apache
> (or Resin's GzipFilter) do the compression should work. I don't think
> there's any need for "hessian_*" values.

It would work just fine (as a matter of fact 1st thing on Monday I'll set up
mod_deflate to test it with the Flash client), but it would also require a bit
more work on the HTTP library code. I know, I know, it's just me moaning at
doing wicked HTTP implementation work, not a real argument. I feel that the
envelope/features things should drive the post-processing of the call/reply
stream though, instead of HTTP headers, as it's a more general approach due to
not being tied to HTTP.

>
> I think those sorts of flags would belong in an envelope, if that was
> necessary.
>
> E 0x01 0x00 features headers hessian-content

Hmm, wouldn't that be:
E 0x01 0x00 features c x01 x00 header* method object* z
E 0x01 0x00 features r x01 x00 header* object|fault z

meaning basically adding a versioned(?) envelope on top of either call or reply.

>
> The call/reply itself shouldn't know or care how it's
> encoded/compresses/digested.

Right, I simply thought of "features" being paired up with the protocol version.

>
>>
>> It just hit me, using HTTP headers is an really bad idea if you want
>> to use Hessian over plain sockets and skip the whole HTTP stuff. Right ?
>
>
> Yes, but a plain socket protocol would probably add some kind of
> flow-control or encapsulation protocol over the main Hessian calls.
>
> You could also have the rule that if a client request was gzipped, the
> response should be gzipped as well. Logically, that's an encapsulation,
> even though it's just determined by looking at the first byte.
>
>> Also on the binary xml / fast web services, I've seen them getting a
>> hell of a beating for that ASN.1 choice. I may be out of my depth here
>> a bit, but why not use CDR (of CORBA) or XDR (of Sun's RPC) ?
>
>
> IIOP is horribly complex from an implementation perspective. The basic
> byte/integer/double is fine, but the encoding of strings and objects is
> ugly.
>

I don't think that's really relevant. The point was that IIOP is standard, it
works, it's got industry support, is maintained by a prestigious group, it's
language independent, it's got loads of implementations in all sorts of
languages (C, C++, Java, C#, Ada etc etc) and is used in sorts of platforms,
from embedded devices, aircraft controllers to bloated Java proxies for
interfacing to the database at Alcatel :-).
In other words, CDR is there already, in terms of usage and implementations
available, so they might as well use that instead of ASN.1. They may be other
considerations that I'm not considering though.

Kind regards,

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